Re: [OS-BUILD PATCHv3] [redhat] turn off legacy drm interfaces
From: Jeremy Cline on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1038#note_556029639 I adjusted the MR slightly to consolidate the now-identical Fedora and ARK settings. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv3 0/0] [redhat] New configs in drivers/gpu
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/563 NOTE: Truncated patchset since committer email 'ptalb...@redhat.com' does not match the submitter's GitLab public email address 'jcl...@redhat.com'. 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_DRM_AMD_DC_DCN3_0: Choose this option if you want to have sienna_cichlid support for display engine Symbol: DRM_AMD_DC_DCN3_0 [=n] Type : bool Defined at drivers/gpu/drm/amd/display/Kconfig:20 Prompt: DCN 3.0 family Depends on: HAS_IOMEM [=y] && DRM [=m] && DRM_AMDGPU [=m] && DRM_AMD_DC [=y] && X86 [=y] && DRM_AMD_DC_DCN [=y] Location: -> Device Drivers -> Graphics support -> AMD GPU (DRM_AMDGPU [=m]) -> Display Engine Configuration --- CONFIG_NOUVEAU_DEBUG_PUSH: Say Y here if you want to enable verbose push buffer debug output and sanity checks. Symbol: NOUVEAU_DEBUG_PUSH [=n] Type : bool Defined at drivers/gpu/drm/nouveau/Kconfig:79 Prompt: Enable additional push buffer debugging Depends on: HAS_IOMEM [=y] && DRM_NOUVEAU [=m] Location: -> Device Drivers -> Graphics support -> Nouveau (NVIDIA) cards (DRM_NOUVEAU [=m]) --- Cc: David Airlie Cc: Adam Jackson Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv3 0/0] [redhat] New configs in drivers/virtio
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/454 NOTE: Truncated patchset since committer email 'ptalb...@redhat.com' does not match the submitter's GitLab public email address 'jcl...@redhat.com'. 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_VIRTIO_MEM: This driver provides access to virtio-mem paravirtualized memory devices, allowing to hotplug and hotunplug memory. This driver was only tested under x86-64, but should theoretically work on all architectures that support memory hotplug and hotremove. If unsure, say M. Symbol: VIRTIO_MEM [=m] Type : tristate Defined at drivers/virtio/Kconfig:81 Prompt: Virtio mem driver Depends on: VIRTIO_MENU [=y] && X86_64 [=y] && VIRTIO [=y] && MEMORY_HOTPLUG_SPARSE [=y] && MEMORY_HOTREMOVE [=y] Location: -> Device Drivers -> Virtio drivers (VIRTIO_MENU [=y]) Selects: CONTIG_ALLOC [=y] --- Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: rhvirt-patc...@redhat.com Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv3 0/0] [redhat] New configs in sound/soc
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/729 NOTE: Truncated patchset since committer email 'acari...@redhat.com' does not match the submitter's GitLab public email address 'jcl...@redhat.com'. 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_SND_SOC_INTEL_CATPT: Enable support for Intel(R) Haswell and Broadwell platforms with I2S codec present. This is a recommended option. Say Y or m if you have such device. If unsure, say N. Symbol: SND_SOC_INTEL_CATPT [=n] Type : tristate Defined at sound/soc/intel/Kconfig:37 Prompt: Haswell and Broadwell Depends on: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_SOC_INTEL_SST_TOPLEVEL [=y] && (ACPI [=y] || COMPILE_TEST [=n]) && DMADEVICES [=y] && SND_DMA_SGBUF [=y] Location: -> Device Drivers -> Sound card support (SOUND [=m]) -> Advanced Linux Sound Architecture (SND [=m]) -> ALSA for SoC audio support (SND_SOC [=m]) -> Intel ASoC SST drivers (SND_SOC_INTEL_SST_TOPLEVEL [=y]) Selects: DW_DMAC_CORE [=y] && SND_SOC_ACPI_INTEL_MATCH [=m] Selected by [n]: - SND_SOC_INTEL_HASWELL [=n] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_SOC_INTEL_SST_TOPLEVEL [=y] --- Cc: Jaroslav Kysela Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv2 0/0] [redhat] New configs in sound/soc
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/729 NOTE: Truncated patchset since committer email 'acari...@redhat.com' does not match the submitter's GitLab public email address 'jcl...@redhat.com'. 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_SND_SOC_INTEL_CATPT: Enable support for Intel(R) Haswell and Broadwell platforms with I2S codec present. This is a recommended option. Say Y or m if you have such device. If unsure, say N. Symbol: SND_SOC_INTEL_CATPT [=n] Type : tristate Defined at sound/soc/intel/Kconfig:37 Prompt: Haswell and Broadwell Depends on: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_SOC_INTEL_SST_TOPLEVEL [=y] && (ACPI [=y] || COMPILE_TEST [=n]) && DMADEVICES [=y] && SND_DMA_SGBUF [=y] Location: -> Device Drivers -> Sound card support (SOUND [=m]) -> Advanced Linux Sound Architecture (SND [=m]) -> ALSA for SoC audio support (SND_SOC [=m]) -> Intel ASoC SST drivers (SND_SOC_INTEL_SST_TOPLEVEL [=y]) Selects: DW_DMAC_CORE [=y] && SND_SOC_ACPI_INTEL_MATCH [=m] Selected by [n]: - SND_SOC_INTEL_HASWELL [=n] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_SOC_INTEL_SST_TOPLEVEL [=y] --- Cc: Jaroslav Kysela Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv4] New configs in arch/powerpc
From: Fedora Kernel Team New configs in arch/powerpc 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_CMDLINE: On some platforms, there is currently no way for the boot loader to pass arguments to the kernel. For these platforms, you can supply some command-line options at build time by entering them here. In most cases you will need to specify the root device here. Symbol: CMDLINE [=] Type : string Defined at arch/powerpc/Kconfig:882 Prompt: Initial kernel command string Location: -> Kernel options Cc: kernel-patc...@redhat.com diff a/redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS b/redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS @@ -0,0 +1 @@ +CONFIG_PPC_QUEUED_SPINLOCKS=y diff a/redhat/configs/common/generic/powerpc/CONFIG_CMDLINE b/redhat/configs/common/generic/powerpc/CONFIG_CMDLINE --- /dev/null +++ b/redhat/configs/common/generic/powerpc/CONFIG_CMDLINE @@ -0,0 +1 @@ +CONFIG_CMDLINE="" diff a/redhat/configs/pending-common/generic/CONFIG_CMDLINE b/redhat/configs/pending-common/generic/CONFIG_CMDLINE --- a/redhat/configs/pending-common/generic/CONFIG_CMDLINE +++ /dev/null @@ -1,17 +0,0 @@ -# CONFIG_CMDLINE: -# -# On some platforms, there is currently no way for the boot loader to -# pass arguments to the kernel. For these platforms, you can supply -# some command-line options at build time by entering them here. In -# most cases you will need to specify the root device here. -# -# Symbol: CMDLINE [=] -# Type : string -# Defined at arch/powerpc/Kconfig:882 -# Prompt: Initial kernel command string -# Location: -# -> Kernel options -# -# -# -CONFIG_CMDLINE="" diff a/redhat/configs/pending-common/generic/CONFIG_PPC_QUEUED_SPINLOCKS b/redhat/configs/pending-common/generic/CONFIG_PPC_QUEUED_SPINLOCKS --- a/redhat/configs/pending-common/generic/CONFIG_PPC_QUEUED_SPINLOCKS +++ /dev/null @@ -1,22 +0,0 @@ -# CONFIG_PPC_QUEUED_SPINLOCKS: -# -# Say Y here to use queued spinlocks which give better scalability and -# fairness on large SMP and NUMA systems without harming single threaded -# performance. -# -# This option is currently experimental, the code is more complex and -# less tested so it defaults to "N" for the moment. -# -# If unsure, say "N". -# -# Symbol: PPC_QUEUED_SPINLOCKS [=n] -# Type : bool -# Defined at arch/powerpc/Kconfig:497 -# Prompt: Queued spinlocks -# Depends on: SMP [=y] -# Location: -# -> Kernel options -# -# -# -# CONFIG_PPC_QUEUED_SPINLOCKS is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/560 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv3 1/2] New configs in arch/powerpc
From: Fedora Kernel Team New configs in arch/powerpc 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_CMDLINE: On some platforms, there is currently no way for the boot loader to pass arguments to the kernel. For these platforms, you can supply some command-line options at build time by entering them here. In most cases you will need to specify the root device here. Symbol: CMDLINE [=] Type : string Defined at arch/powerpc/Kconfig:882 Prompt: Initial kernel command string Location: -> Kernel options Cc: kernel-patc...@redhat.com diff a/redhat/configs/common/generic/CONFIG_CMDLINE b/redhat/configs/common/generic/CONFIG_CMDLINE --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_CMDLINE @@ -0,0 +1 @@ +CONFIG_CMDLINE="" diff a/redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS b/redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS @@ -0,0 +1 @@ +# CONFIG_PPC_QUEUED_SPINLOCKS is not set diff a/redhat/configs/pending-common/generic/CONFIG_CMDLINE b/redhat/configs/pending-common/generic/CONFIG_CMDLINE --- a/redhat/configs/pending-common/generic/CONFIG_CMDLINE +++ /dev/null @@ -1,17 +0,0 @@ -# CONFIG_CMDLINE: -# -# On some platforms, there is currently no way for the boot loader to -# pass arguments to the kernel. For these platforms, you can supply -# some command-line options at build time by entering them here. In -# most cases you will need to specify the root device here. -# -# Symbol: CMDLINE [=] -# Type : string -# Defined at arch/powerpc/Kconfig:882 -# Prompt: Initial kernel command string -# Location: -# -> Kernel options -# -# -# -CONFIG_CMDLINE="" diff a/redhat/configs/pending-common/generic/CONFIG_PPC_QUEUED_SPINLOCKS b/redhat/configs/pending-common/generic/CONFIG_PPC_QUEUED_SPINLOCKS --- a/redhat/configs/pending-common/generic/CONFIG_PPC_QUEUED_SPINLOCKS +++ /dev/null @@ -1,22 +0,0 @@ -# CONFIG_PPC_QUEUED_SPINLOCKS: -# -# Say Y here to use queued spinlocks which give better scalability and -# fairness on large SMP and NUMA systems without harming single threaded -# performance. -# -# This option is currently experimental, the code is more complex and -# less tested so it defaults to "N" for the moment. -# -# If unsure, say "N". -# -# Symbol: PPC_QUEUED_SPINLOCKS [=n] -# Type : bool -# Defined at arch/powerpc/Kconfig:497 -# Prompt: Queued spinlocks -# Depends on: SMP [=y] -# Location: -# -> Kernel options -# -# -# -# CONFIG_PPC_QUEUED_SPINLOCKS is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/560 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv3 2/2] Update CONFIG_PPC_QUEUED_SPINLOCKS
From: Justin Forbes Update CONFIG_PPC_QUEUED_SPINLOCKS diff a/redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS b/redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS --- a/redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS +++ b/redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS @@ -1 +1 @@ -# CONFIG_PPC_QUEUED_SPINLOCKS is not set +CONFIG_PPC_QUEUED_SPINLOCKS=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/560 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv3 0/2] [redhat] New configs in arch/powerpc
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/560 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_CMDLINE: On some platforms, there is currently no way for the boot loader to pass arguments to the kernel. For these platforms, you can supply some command-line options at build time by entering them here. In most cases you will need to specify the root device here. Symbol: CMDLINE [=] Type : string Defined at arch/powerpc/Kconfig:882 Prompt: Initial kernel command string Location: -> Kernel options --- CONFIG_PPC_QUEUED_SPINLOCKS: Say Y here to use queued spinlocks which give better scalability and fairness on large SMP and NUMA systems without harming single threaded performance. This option is currently experimental, the code is more complex and less tested so it defaults to "N" for the moment. If unsure, say "N". Symbol: PPC_QUEUED_SPINLOCKS [=n] Type : bool Defined at arch/powerpc/Kconfig:497 Prompt: Queued spinlocks Depends on: SMP [=y] Location: -> Kernel options --- Cc: kernel-patc...@redhat.com Cc: Waiman Long Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv3] [redhat] New configs in security/keys
From: Fedora Kernel Team [redhat] New configs in security/keys Hi, As part of the ongoing rebase effort, the following configuration options need to be reviewed. CONFIG_KEY_NOTIFICATIONS 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. --- Signed-off-by: Fedora Kernel Team Signed-off-by: Patrick Talbert diff a/redhat/configs/common/generic/CONFIG_KEY_NOTIFICATIONS b/redhat/configs/common/generic/CONFIG_KEY_NOTIFICATIONS --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_KEY_NOTIFICATIONS @@ -0,0 +1 @@ +CONFIG_KEY_NOTIFICATIONS=y diff a/redhat/configs/fedora/generic/CONFIG_KEY_NOTIFICATIONS b/redhat/configs/fedora/generic/CONFIG_KEY_NOTIFICATIONS --- a/redhat/configs/fedora/generic/CONFIG_KEY_NOTIFICATIONS +++ /dev/null @@ -1,19 +0,0 @@ -# CONFIG_KEY_NOTIFICATIONS: -# -# This option provides support for getting change notifications on keys -# and keyrings on which the caller has View permission. This makes use -# of the /dev/watch_queue misc device to handle the notification -# buffer and provides KEYCTL_WATCH_KEY to enable/disable watches. -# -# Symbol: KEY_NOTIFICATIONS [=n] -# Type : bool -# Defined at security/keys/Kconfig:118 -# Prompt: Provide key/keyring change notifications -# Depends on: KEYS [=y] && WATCH_QUEUE [=y] -# Location: -# -> Security options -# -> Enable access key retention support (KEYS [=y]) -# -# -# -CONFIG_KEY_NOTIFICATIONS=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/464 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv4 2/2] Update CONFIG_SPI_AMD based on Prarit's recommendations
From: Justin Forbes Update CONFIG_SPI_AMD based on Prarit's recommendations Cc: Al Stone diff a/redhat/configs/common/generic/CONFIG_SPI_AMD b/redhat/configs/common/generic/CONFIG_SPI_AMD --- a/redhat/configs/common/generic/CONFIG_SPI_AMD +++ b/redhat/configs/common/generic/CONFIG_SPI_AMD @@ -1 +1 @@ -# CONFIG_SPI_AMD is not set +CONFIG_SPI_AMD=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/396 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv4 0/2] [redhat] New configs in drivers/spi
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/396 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_SPI_AMD: Enables SPI controller driver for AMD SoC. Symbol: SPI_AMD [=n] Type : tristate Defined at drivers/spi/Kconfig:917 Prompt: AMD SPI controller Depends on: SPI [=y] && SPI_MASTER [=y] && (SPI_MASTER [=y] || COMPILE_TEST [=n]) Location: -> Device Drivers -> SPI support (SPI [=y]) --- Cc: Al Stone Cc: Prarit Bhargava Signed-off-by: CKI@GitLab ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv4 1/2] [redhat] New configs in drivers/spi
From: CKI@GitLab [redhat] New configs in drivers/spi 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_SPI_AMD: Enables SPI controller driver for AMD SoC. Symbol: SPI_AMD [=n] Type : tristate Defined at drivers/spi/Kconfig:917 Prompt: AMD SPI controller Depends on: SPI [=y] && SPI_MASTER [=y] && (SPI_MASTER [=y] || COMPILE_TEST [=n]) Location: -> Device Drivers -> SPI support (SPI [=y]) --- Signed-off-by: CKI@GitLab diff a/redhat/configs/common/generic/CONFIG_SPI_AMD b/redhat/configs/common/generic/CONFIG_SPI_AMD --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_SPI_AMD @@ -0,0 +1 @@ +# CONFIG_SPI_AMD is not set diff a/redhat/configs/pending-common/generic/CONFIG_SPI_AMD b/redhat/configs/pending-common/generic/CONFIG_SPI_AMD --- a/redhat/configs/pending-common/generic/CONFIG_SPI_AMD +++ /dev/null @@ -1,16 +0,0 @@ -# CONFIG_SPI_AMD: -# -# Enables SPI controller driver for AMD SoC. -# -# Symbol: SPI_AMD [=n] -# Type : tristate -# Defined at drivers/spi/Kconfig:917 -# Prompt: AMD SPI controller -# Depends on: SPI [=y] && SPI_MASTER [=y] && (SPI_MASTER [=y] || COMPILE_TEST [=n]) -# Location: -# -> Device Drivers -# -> SPI support (SPI [=y]) -# -# -# -# CONFIG_SPI_AMD is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/396 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv3] New configs in lib/Kconfig.debug
From: Fedora Kernel Team New configs in lib/Kconfig.debug 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_DEBUG_FS_ALLOW_ALL: No restrictions apply. Both API and filesystem registration is on. This is the normal default operation. Symbol: DEBUG_FS_ALLOW_ALL [=y] Type : bool Defined at lib/Kconfig.debug:500 Prompt: Access normal Depends on: Location: -> Kernel hacking -> Generic Kernel Debugging Instruments -> Debug Filesystem (DEBUG_FS [=y]) -> Debugfs default access ( [=y]) Cc: Prarit Bhargava diff a/redhat/configs/common/generic/CONFIG_DEBUG_FS_ALLOW_ALL b/redhat/configs/common/generic/CONFIG_DEBUG_FS_ALLOW_ALL --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_DEBUG_FS_ALLOW_ALL @@ -0,0 +1 @@ +CONFIG_DEBUG_FS_ALLOW_ALL=y diff a/redhat/configs/common/generic/CONFIG_DEBUG_FS_ALLOW_NONE b/redhat/configs/common/generic/CONFIG_DEBUG_FS_ALLOW_NONE --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_DEBUG_FS_ALLOW_NONE @@ -0,0 +1 @@ +# CONFIG_DEBUG_FS_ALLOW_NONE is not set diff a/redhat/configs/common/generic/CONFIG_DEBUG_FS_DISALLOW_MOUNT b/redhat/configs/common/generic/CONFIG_DEBUG_FS_DISALLOW_MOUNT --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_DEBUG_FS_DISALLOW_MOUNT @@ -0,0 +1 @@ +# CONFIG_DEBUG_FS_DISALLOW_MOUNT is not set diff a/redhat/configs/pending-common/generic/CONFIG_DEBUG_FS_ALLOW_ALL b/redhat/configs/pending-common/generic/CONFIG_DEBUG_FS_ALLOW_ALL --- a/redhat/configs/pending-common/generic/CONFIG_DEBUG_FS_ALLOW_ALL +++ /dev/null @@ -1,19 +0,0 @@ -# CONFIG_DEBUG_FS_ALLOW_ALL: -# -# No restrictions apply. Both API and filesystem registration -# is on. This is the normal default operation. -# -# Symbol: DEBUG_FS_ALLOW_ALL [=y] -# Type : bool -# Defined at lib/Kconfig.debug:500 -# Prompt: Access normal -# Depends on: -# Location: -# -> Kernel hacking -# -> Generic Kernel Debugging Instruments -# -> Debug Filesystem (DEBUG_FS [=y]) -# -> Debugfs default access ( [=y]) -# -# -# -CONFIG_DEBUG_FS_ALLOW_ALL=y diff a/redhat/configs/pending-common/generic/CONFIG_DEBUG_FS_ALLOW_NONE b/redhat/configs/pending-common/generic/CONFIG_DEBUG_FS_ALLOW_NONE --- a/redhat/configs/pending-common/generic/CONFIG_DEBUG_FS_ALLOW_NONE +++ /dev/null @@ -1,20 +0,0 @@ -# CONFIG_DEBUG_FS_ALLOW_NONE: -# -# Access is off. Clients get -PERM when trying to create nodes in -# debugfs tree and debugfs is not registered as a filesystem. -# Client can then back-off or continue without debugfs access. -# -# Symbol: DEBUG_FS_ALLOW_NONE [=n] -# Type : bool -# Defined at lib/Kconfig.debug:513 -# Prompt: No access -# Depends on: -# Location: -# -> Kernel hacking -# -> Generic Kernel Debugging Instruments -# -> Debug Filesystem (DEBUG_FS [=y]) -# -> Debugfs default access ( [=y]) -# -# -# -# CONFIG_DEBUG_FS_ALLOW_NONE is not set diff a/redhat/configs/pending-common/generic/CONFIG_DEBUG_FS_DISALLOW_MOUNT b/redhat/configs/pending-common/generic/CONFIG_DEBUG_FS_DISALLOW_MOUNT --- a/redhat/configs/pending-common/generic/CONFIG_DEBUG_FS_DISALLOW_MOUNT +++ /dev/null @@ -1,20 +0,0 @@ -# CONFIG_DEBUG_FS_DISALLOW_MOUNT: -# -# The API is open but filesystem is not loaded. Clients can still do -# their work and read with debug tools that do not need -# debugfs filesystem. -# -# Symbol: DEBUG_FS_DISALLOW_MOUNT [=n] -# Type : bool -# Defined at lib/Kconfig.debug:506 -# Prompt: Do not register debugfs as filesystem -# Depends on: -# Location: -# -> Kernel hacking -# -> Generic Kernel Debugging Instruments -# -> Debug Filesystem (DEBUG_FS [=y]) -# -> Debugfs default access ( [=y]) -# -# -# -# CONFIG_DEBUG_FS_DISALLOW_MOUNT is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/580 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv4 2/2] Update CONFIG_WATCH_QUEUE
From: Patrick Talbert Update CONFIG_WATCH_QUEUE diff a/redhat/configs/common/generic/CONFIG_KEY_NOTIFICATIONS b/redhat/configs/common/generic/CONFIG_KEY_NOTIFICATIONS --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_KEY_NOTIFICATIONS @@ -0,0 +1 @@ +CONFIG_KEY_NOTIFICATIONS=y diff a/redhat/configs/common/generic/CONFIG_WATCH_QUEUE b/redhat/configs/common/generic/CONFIG_WATCH_QUEUE --- a/redhat/configs/common/generic/CONFIG_WATCH_QUEUE +++ b/redhat/configs/common/generic/CONFIG_WATCH_QUEUE @@ -1 +1 @@ -# CONFIG_WATCH_QUEUE is not set +CONFIG_WATCH_QUEUE=y diff a/redhat/configs/fedora/generic/CONFIG_KEY_NOTIFICATIONS b/redhat/configs/fedora/generic/CONFIG_KEY_NOTIFICATIONS --- a/redhat/configs/fedora/generic/CONFIG_KEY_NOTIFICATIONS +++ /dev/null @@ -1,19 +0,0 @@ -# CONFIG_KEY_NOTIFICATIONS: -# -# This option provides support for getting change notifications on keys -# and keyrings on which the caller has View permission. This makes use -# of the /dev/watch_queue misc device to handle the notification -# buffer and provides KEYCTL_WATCH_KEY to enable/disable watches. -# -# Symbol: KEY_NOTIFICATIONS [=n] -# Type : bool -# Defined at security/keys/Kconfig:118 -# Prompt: Provide key/keyring change notifications -# Depends on: KEYS [=y] && WATCH_QUEUE [=y] -# Location: -# -> Security options -# -> Enable access key retention support (KEYS [=y]) -# -# -# -CONFIG_KEY_NOTIFICATIONS=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/462 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv4 0/2] [redhat] New configs in init/Kconfig
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/462 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_WATCH_QUEUE: This is a general notification queue for the kernel to pass events to userspace by splicing them into pipes. It can be used in conjunction with watches for key/keyring change notifications and device notifications. See Documentation/watch_queue.rst Symbol: WATCH_QUEUE [=n] Type : bool Defined at init/Kconfig:370 Prompt: General notification queue Location: -> General setup --- Cc: Prarit Bhargava Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv4 1/2] New configs in init/Kconfig
From: Fedora Kernel Team New configs in init/Kconfig 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_WATCH_QUEUE: This is a general notification queue for the kernel to pass events to userspace by splicing them into pipes. It can be used in conjunction with watches for key/keyring change notifications and device notifications. See Documentation/watch_queue.rst Symbol: WATCH_QUEUE [=n] Type : bool Defined at init/Kconfig:370 Prompt: General notification queue Location: -> General setup Cc: Prarit Bhargava diff a/redhat/configs/common/generic/CONFIG_WATCH_QUEUE b/redhat/configs/common/generic/CONFIG_WATCH_QUEUE --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_WATCH_QUEUE @@ -0,0 +1 @@ +# CONFIG_WATCH_QUEUE is not set diff a/redhat/configs/pending-common/generic/CONFIG_WATCH_QUEUE b/redhat/configs/pending-common/generic/CONFIG_WATCH_QUEUE --- a/redhat/configs/pending-common/generic/CONFIG_WATCH_QUEUE +++ /dev/null @@ -1,20 +0,0 @@ -# CONFIG_WATCH_QUEUE: -# -# -# This is a general notification queue for the kernel to pass events to -# userspace by splicing them into pipes. It can be used in conjunction -# with watches for key/keyring change notifications and device -# notifications. -# -# See Documentation/watch_queue.rst -# -# Symbol: WATCH_QUEUE [=n] -# Type : bool -# Defined at init/Kconfig:370 -# Prompt: General notification queue -# Location: -# -> General setup -# -# -# -# CONFIG_WATCH_QUEUE is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/462 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv3 2/2] Update CONFIG_WATCH_QUEUE
From: Patrick Talbert Update CONFIG_WATCH_QUEUE diff a/redhat/configs/common/generic/CONFIG_WATCH_QUEUE b/redhat/configs/common/generic/CONFIG_WATCH_QUEUE --- a/redhat/configs/common/generic/CONFIG_WATCH_QUEUE +++ b/redhat/configs/common/generic/CONFIG_WATCH_QUEUE @@ -1 +1 @@ -# CONFIG_WATCH_QUEUE is not set +CONFIG_WATCH_QUEUE=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/462 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv3 1/2] New configs in init/Kconfig
From: Fedora Kernel Team New configs in init/Kconfig 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_WATCH_QUEUE: This is a general notification queue for the kernel to pass events to userspace by splicing them into pipes. It can be used in conjunction with watches for key/keyring change notifications and device notifications. See Documentation/watch_queue.rst Symbol: WATCH_QUEUE [=n] Type : bool Defined at init/Kconfig:370 Prompt: General notification queue Location: -> General setup Cc: Prarit Bhargava diff a/redhat/configs/common/generic/CONFIG_WATCH_QUEUE b/redhat/configs/common/generic/CONFIG_WATCH_QUEUE --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_WATCH_QUEUE @@ -0,0 +1 @@ +# CONFIG_WATCH_QUEUE is not set diff a/redhat/configs/pending-common/generic/CONFIG_WATCH_QUEUE b/redhat/configs/pending-common/generic/CONFIG_WATCH_QUEUE --- a/redhat/configs/pending-common/generic/CONFIG_WATCH_QUEUE +++ /dev/null @@ -1,20 +0,0 @@ -# CONFIG_WATCH_QUEUE: -# -# -# This is a general notification queue for the kernel to pass events to -# userspace by splicing them into pipes. It can be used in conjunction -# with watches for key/keyring change notifications and device -# notifications. -# -# See Documentation/watch_queue.rst -# -# Symbol: WATCH_QUEUE [=n] -# Type : bool -# Defined at init/Kconfig:370 -# Prompt: General notification queue -# Location: -# -> General setup -# -# -# -# CONFIG_WATCH_QUEUE is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/462 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv3 0/2] [redhat] New configs in init/Kconfig
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/462 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_WATCH_QUEUE: This is a general notification queue for the kernel to pass events to userspace by splicing them into pipes. It can be used in conjunction with watches for key/keyring change notifications and device notifications. See Documentation/watch_queue.rst Symbol: WATCH_QUEUE [=n] Type : bool Defined at init/Kconfig:370 Prompt: General notification queue Location: -> General setup --- Cc: Prarit Bhargava Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv3 2/2] Update CONFIG_DMABUF_HEAPS_SYSTEM
From: Patrick Talbert Update CONFIG_DMABUF_HEAPS_SYSTEM diff a/redhat/configs/common/generic/CONFIG_DMABUF_HEAPS_SYSTEM b/redhat/configs/common/generic/CONFIG_DMABUF_HEAPS_SYSTEM --- a/redhat/configs/common/generic/CONFIG_DMABUF_HEAPS_SYSTEM +++ b/redhat/configs/common/generic/CONFIG_DMABUF_HEAPS_SYSTEM @@ -1 +1 @@ -# CONFIG_DMABUF_HEAPS_SYSTEM is not set +CONFIG_DMABUF_HEAPS_SYSTEM=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/457 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv3 1/2] New configs in drivers/dma-buf
From: Fedora Kernel Team New configs in drivers/dma-buf 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_DMABUF_HEAPS_SYSTEM: Choose this option to enable the system dmabuf heap. The system heap is backed by pages from the buddy allocator. If in doubt, say Y. Symbol: DMABUF_HEAPS_SYSTEM [=n] Type : bool Defined at drivers/dma-buf/heaps/Kconfig:1 Prompt: DMA-BUF System Heap Depends on: DMABUF_HEAPS [=y] Location: -> Device Drivers -> DMABUF options -> DMA-BUF Userland Memory Heaps (DMABUF_HEAPS [=y]) Cc: Lyude Paul diff a/redhat/configs/common/generic/CONFIG_DMABUF_HEAPS_SYSTEM b/redhat/configs/common/generic/CONFIG_DMABUF_HEAPS_SYSTEM --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_DMABUF_HEAPS_SYSTEM @@ -0,0 +1 @@ +# CONFIG_DMABUF_HEAPS_SYSTEM is not set diff a/redhat/configs/pending-common/generic/CONFIG_DMABUF_HEAPS_SYSTEM b/redhat/configs/pending-common/generic/CONFIG_DMABUF_HEAPS_SYSTEM --- a/redhat/configs/pending-common/generic/CONFIG_DMABUF_HEAPS_SYSTEM +++ /dev/null @@ -1,18 +0,0 @@ -# CONFIG_DMABUF_HEAPS_SYSTEM: -# -# Choose this option to enable the system dmabuf heap. The system heap -# is backed by pages from the buddy allocator. If in doubt, say Y. -# -# Symbol: DMABUF_HEAPS_SYSTEM [=n] -# Type : bool -# Defined at drivers/dma-buf/heaps/Kconfig:1 -# Prompt: DMA-BUF System Heap -# Depends on: DMABUF_HEAPS [=y] -# Location: -# -> Device Drivers -# -> DMABUF options -# -> DMA-BUF Userland Memory Heaps (DMABUF_HEAPS [=y]) -# -# -# -# CONFIG_DMABUF_HEAPS_SYSTEM is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/457 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv3 0/2] [redhat] New configs in drivers/dma-buf
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/457 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_DMABUF_HEAPS_SYSTEM: Choose this option to enable the system dmabuf heap. The system heap is backed by pages from the buddy allocator. If in doubt, say Y. Symbol: DMABUF_HEAPS_SYSTEM [=n] Type : bool Defined at drivers/dma-buf/heaps/Kconfig:1 Prompt: DMA-BUF System Heap Depends on: DMABUF_HEAPS [=y] Location: -> Device Drivers -> DMABUF options -> DMA-BUF Userland Memory Heaps (DMABUF_HEAPS [=y]) --- Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv5 2/2] Update CONFIG_DEBUG_VM_PGTABLE
From: Patrick Talbert Update CONFIG_DEBUG_VM_PGTABLE diff a/redhat/configs/common/debug/CONFIG_DEBUG_VM_PGTABLE b/redhat/configs/common/debug/CONFIG_DEBUG_VM_PGTABLE --- /dev/null +++ b/redhat/configs/common/debug/CONFIG_DEBUG_VM_PGTABLE @@ -0,0 +1 @@ +CONFIG_DEBUG_VM_PGTABLE=y diff a/redhat/configs/fedora/debug/CONFIG_DEBUG_VM_PGTABLE b/redhat/configs/fedora/debug/CONFIG_DEBUG_VM_PGTABLE --- a/redhat/configs/fedora/debug/CONFIG_DEBUG_VM_PGTABLE +++ /dev/null @@ -1,24 +0,0 @@ -# CONFIG_DEBUG_VM_PGTABLE: -# -# This option provides a debug method which can be used to test -# architecture page table helper functions on various platforms in -# verifying if they comply with expected generic MM semantics. This -# will help architecture code in making sure that any changes or -# new additions of these helpers still conform to expected -# semantics of the generic MM. Platforms will have to opt in for -# this through ARCH_HAS_DEBUG_VM_PGTABLE. -# -# If unsure, say N. -# -# Symbol: DEBUG_VM_PGTABLE [=y] -# Type : bool -# Defined at lib/Kconfig.debug:702 -# Prompt: Debug arch page table for semantics compliance -# Depends on: MMU [=y] && ARCH_HAS_DEBUG_VM_PGTABLE [=y] -# Location: -# -> Kernel hacking -# -> Memory Debugging -# -# -# -CONFIG_DEBUG_VM_PGTABLE=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/425 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv5 1/2] New configs in lib/Kconfig.debug
From: Fedora Kernel Team New configs in lib/Kconfig.debug 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_DEBUG_VM_PGTABLE: This option provides a debug method which can be used to test architecture page table helper functions on various platforms in verifying if they comply with expected generic MM semantics. This will help architecture code in making sure that any changes or new additions of these helpers still conform to expected semantics of the generic MM. Platforms will have to opt in for this through ARCH_HAS_DEBUG_VM_PGTABLE. If unsure, say N. Symbol: DEBUG_VM_PGTABLE [=n] Type : bool Defined at lib/Kconfig.debug:702 Prompt: Debug arch page table for semantics compliance Depends on: MMU [=y] && ARCH_HAS_DEBUG_VM_PGTABLE [=y] Location: -> Kernel hacking -> Memory Debugging Cc: Prarit Bhargava diff a/redhat/configs/common/generic/CONFIG_DEBUG_VM_PGTABLE b/redhat/configs/common/generic/CONFIG_DEBUG_VM_PGTABLE --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_DEBUG_VM_PGTABLE @@ -0,0 +1 @@ +# CONFIG_DEBUG_VM_PGTABLE is not set diff a/redhat/configs/common/generic/CONFIG_TEST_BITOPS b/redhat/configs/common/generic/CONFIG_TEST_BITOPS --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_TEST_BITOPS @@ -0,0 +1 @@ +# CONFIG_TEST_BITOPS is not set diff a/redhat/configs/pending-common/generic/CONFIG_DEBUG_VM_PGTABLE b/redhat/configs/pending-common/generic/CONFIG_DEBUG_VM_PGTABLE --- a/redhat/configs/pending-common/generic/CONFIG_DEBUG_VM_PGTABLE +++ /dev/null @@ -1,24 +0,0 @@ -# CONFIG_DEBUG_VM_PGTABLE: -# -# This option provides a debug method which can be used to test -# architecture page table helper functions on various platforms in -# verifying if they comply with expected generic MM semantics. This -# will help architecture code in making sure that any changes or -# new additions of these helpers still conform to expected -# semantics of the generic MM. Platforms will have to opt in for -# this through ARCH_HAS_DEBUG_VM_PGTABLE. -# -# If unsure, say N. -# -# Symbol: DEBUG_VM_PGTABLE [=n] -# Type : bool -# Defined at lib/Kconfig.debug:702 -# Prompt: Debug arch page table for semantics compliance -# Depends on: MMU [=y] && ARCH_HAS_DEBUG_VM_PGTABLE [=y] -# Location: -# -> Kernel hacking -# -> Memory Debugging -# -# -# -# CONFIG_DEBUG_VM_PGTABLE is not set diff a/redhat/configs/pending-common/generic/CONFIG_TEST_BITOPS b/redhat/configs/pending-common/generic/CONFIG_TEST_BITOPS --- a/redhat/configs/pending-common/generic/CONFIG_TEST_BITOPS +++ /dev/null @@ -1,24 +0,0 @@ -# CONFIG_TEST_BITOPS: -# -# This builds the "test_bitops" module that is much like the -# TEST_LKM module except that it does a basic exercise of the -# clear_bit and set_bit macros to make sure there are no compiler -# warnings from C=1 sparse checker or -Wextra compilations. It has -# no dependencies and doesn't run or load unless explicitly requested -# by name. for example: modprobe test_bitops. -# -# If unsure, say N. -# -# Symbol: TEST_BITOPS [=n] -# Type : tristate -# Defined at lib/Kconfig.debug:2025 -# Prompt: Test module for compilation of clear_bit/set_bit operations -# Depends on: RUNTIME_TESTING_MENU [=y] && m && MODULES [=y] -# Location: -# -> Kernel hacking -# -> Kernel Testing and Coverage -# -> Runtime Testing (RUNTIME_TESTING_MENU [=y]) -# -# -# -# CONFIG_TEST_BITOPS is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/425 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv5 0/2] [redhat] New configs in lib/Kconfig.debug
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/425 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_DEBUG_VM_PGTABLE: This option provides a debug method which can be used to test architecture page table helper functions on various platforms in verifying if they comply with expected generic MM semantics. This will help architecture code in making sure that any changes or new additions of these helpers still conform to expected semantics of the generic MM. Platforms will have to opt in for this through ARCH_HAS_DEBUG_VM_PGTABLE. If unsure, say N. Symbol: DEBUG_VM_PGTABLE [=n] Type : bool Defined at lib/Kconfig.debug:702 Prompt: Debug arch page table for semantics compliance Depends on: MMU [=y] && ARCH_HAS_DEBUG_VM_PGTABLE [=y] Location: -> Kernel hacking -> Memory Debugging --- CONFIG_TEST_BITOPS: This builds the "test_bitops" module that is much like the TEST_LKM module except that it does a basic exercise of the clear_bit and set_bit macros to make sure there are no compiler warnings from C=1 sparse checker or -Wextra compilations. It has no dependencies and doesn't run or load unless explicitly requested by name. for example: modprobe test_bitops. If unsure, say N. Symbol: TEST_BITOPS [=n] Type : tristate Defined at lib/Kconfig.debug:2025 Prompt: Test module for compilation of clear_bit/set_bit operations Depends on: RUNTIME_TESTING_MENU [=y] && m && MODULES [=y] Location: -> Kernel hacking -> Kernel Testing and Coverage -> Runtime Testing (RUNTIME_TESTING_MENU [=y]) --- Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv5 1/2] [redhat] New configs in drivers/vfio
From: Fedora Kernel Team [redhat] New configs in drivers/vfio 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_VFIO_PCI_ZDEV: Enabling this option exposes VFIO capabilities containing hardware configuration for zPCI devices. This enables userspace (e.g. QEMU) to supply proper configuration values instead of hard-coded defaults for zPCI devices passed through via VFIO on s390. Say Y here. Symbol: VFIO_PCI_ZDEV [=y] Type : bool Defined at drivers/vfio/pci/Kconfig:49 Prompt: VFIO PCI ZPCI device CLP support Depends on: VFIO_PCI [=m] && S390 [=y] Location: -> Device Drivers -> VFIO Non-Privileged userspace driver framework (VFIO [=m]) -> VFIO support for PCI devices (VFIO_PCI [=m]) --- Cc: Alex Williamson Cc: Eric Auger Cc: rhvirt-patc...@redhat.com Signed-off-by: Fedora Kernel Team diff a/redhat/configs/common/generic/CONFIG_VFIO_PCI_ZDEV b/redhat/configs/common/generic/CONFIG_VFIO_PCI_ZDEV --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_VFIO_PCI_ZDEV @@ -0,0 +1 @@ +CONFIG_VFIO_PCI_ZDEV=y diff a/redhat/configs/pending-common/generic/CONFIG_VFIO_PCI_ZDEV b/redhat/configs/pending-common/generic/CONFIG_VFIO_PCI_ZDEV --- a/redhat/configs/pending-common/generic/CONFIG_VFIO_PCI_ZDEV +++ /dev/null @@ -1,22 +0,0 @@ -# CONFIG_VFIO_PCI_ZDEV: -# -# Enabling this option exposes VFIO capabilities containing hardware -# configuration for zPCI devices. This enables userspace (e.g. QEMU) -# to supply proper configuration values instead of hard-coded defaults -# for zPCI devices passed through via VFIO on s390. -# -# Say Y here. -# -# Symbol: VFIO_PCI_ZDEV [=y] -# Type : bool -# Defined at drivers/vfio/pci/Kconfig:49 -# Prompt: VFIO PCI ZPCI device CLP support -# Depends on: VFIO_PCI [=m] && S390 [=y] -# Location: -# -> Device Drivers -# -> VFIO Non-Privileged userspace driver framework (VFIO [=m]) -# -> VFIO support for PCI devices (VFIO_PCI [=m]) -# -# -# -CONFIG_VFIO_PCI_ZDEV=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/748 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv5 0/2] [redhat] New configs in drivers/vfio
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/748 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_VFIO_PCI_ZDEV: Enabling this option exposes VFIO capabilities containing hardware configuration for zPCI devices. This enables userspace (e.g. QEMU) to supply proper configuration values instead of hard-coded defaults for zPCI devices passed through via VFIO on s390. Say Y here. Symbol: VFIO_PCI_ZDEV [=y] Type : bool Defined at drivers/vfio/pci/Kconfig:49 Prompt: VFIO PCI ZPCI device CLP support Depends on: VFIO_PCI [=m] && S390 [=y] Location: -> Device Drivers -> VFIO Non-Privileged userspace driver framework (VFIO [=m]) -> VFIO support for PCI devices (VFIO_PCI [=m]) --- Cc: Alex Williamson Cc: Eric Auger Cc: rhvirt-patc...@redhat.com Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv4 1/2] [redhat] New configs in drivers/vfio
From: Fedora Kernel Team [redhat] New configs in drivers/vfio 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_VFIO_PCI_ZDEV: Enabling this option exposes VFIO capabilities containing hardware configuration for zPCI devices. This enables userspace (e.g. QEMU) to supply proper configuration values instead of hard-coded defaults for zPCI devices passed through via VFIO on s390. Say Y here. Symbol: VFIO_PCI_ZDEV [=y] Type : bool Defined at drivers/vfio/pci/Kconfig:49 Prompt: VFIO PCI ZPCI device CLP support Depends on: VFIO_PCI [=m] && S390 [=y] Location: -> Device Drivers -> VFIO Non-Privileged userspace driver framework (VFIO [=m]) -> VFIO support for PCI devices (VFIO_PCI [=m]) --- Cc: Alex Williamson Cc: Eric Auger Cc: rhvirt-patc...@redhat.com Signed-off-by: Fedora Kernel Team diff a/redhat/configs/common/generic/CONFIG_VFIO_PCI_ZDEV b/redhat/configs/common/generic/CONFIG_VFIO_PCI_ZDEV --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_VFIO_PCI_ZDEV @@ -0,0 +1 @@ +CONFIG_VFIO_PCI_ZDEV=y diff a/redhat/configs/pending-common/generic/CONFIG_VFIO_PCI_ZDEV b/redhat/configs/pending-common/generic/CONFIG_VFIO_PCI_ZDEV --- a/redhat/configs/pending-common/generic/CONFIG_VFIO_PCI_ZDEV +++ /dev/null @@ -1,22 +0,0 @@ -# CONFIG_VFIO_PCI_ZDEV: -# -# Enabling this option exposes VFIO capabilities containing hardware -# configuration for zPCI devices. This enables userspace (e.g. QEMU) -# to supply proper configuration values instead of hard-coded defaults -# for zPCI devices passed through via VFIO on s390. -# -# Say Y here. -# -# Symbol: VFIO_PCI_ZDEV [=y] -# Type : bool -# Defined at drivers/vfio/pci/Kconfig:49 -# Prompt: VFIO PCI ZPCI device CLP support -# Depends on: VFIO_PCI [=m] && S390 [=y] -# Location: -# -> Device Drivers -# -> VFIO Non-Privileged userspace driver framework (VFIO [=m]) -# -> VFIO support for PCI devices (VFIO_PCI [=m]) -# -# -# -CONFIG_VFIO_PCI_ZDEV=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/748 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv4 0/2] [redhat] New configs in drivers/vfio
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/748 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_VFIO_PCI_ZDEV: Enabling this option exposes VFIO capabilities containing hardware configuration for zPCI devices. This enables userspace (e.g. QEMU) to supply proper configuration values instead of hard-coded defaults for zPCI devices passed through via VFIO on s390. Say Y here. Symbol: VFIO_PCI_ZDEV [=y] Type : bool Defined at drivers/vfio/pci/Kconfig:49 Prompt: VFIO PCI ZPCI device CLP support Depends on: VFIO_PCI [=m] && S390 [=y] Location: -> Device Drivers -> VFIO Non-Privileged userspace driver framework (VFIO [=m]) -> VFIO support for PCI devices (VFIO_PCI [=m]) --- Cc: Alex Williamson Cc: Eric Auger Cc: rhvirt-patc...@redhat.com Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv3 1/2] [redhat] New configs in drivers/vfio
From: Fedora Kernel Team [redhat] New configs in drivers/vfio 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_VFIO_PCI_ZDEV: Enabling this option exposes VFIO capabilities containing hardware configuration for zPCI devices. This enables userspace (e.g. QEMU) to supply proper configuration values instead of hard-coded defaults for zPCI devices passed through via VFIO on s390. Say Y here. Symbol: VFIO_PCI_ZDEV [=y] Type : bool Defined at drivers/vfio/pci/Kconfig:49 Prompt: VFIO PCI ZPCI device CLP support Depends on: VFIO_PCI [=m] && S390 [=y] Location: -> Device Drivers -> VFIO Non-Privileged userspace driver framework (VFIO [=m]) -> VFIO support for PCI devices (VFIO_PCI [=m]) --- Cc: Alex Williamson Cc: Eric Auger Cc: rhvirt-patc...@redhat.com Signed-off-by: Fedora Kernel Team diff a/redhat/configs/common/generic/CONFIG_VFIO_PCI_ZDEV b/redhat/configs/common/generic/CONFIG_VFIO_PCI_ZDEV --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_VFIO_PCI_ZDEV @@ -0,0 +1 @@ +CONFIG_VFIO_PCI_ZDEV=y diff a/redhat/configs/pending-common/generic/CONFIG_VFIO_PCI_ZDEV b/redhat/configs/pending-common/generic/CONFIG_VFIO_PCI_ZDEV --- a/redhat/configs/pending-common/generic/CONFIG_VFIO_PCI_ZDEV +++ /dev/null @@ -1,22 +0,0 @@ -# CONFIG_VFIO_PCI_ZDEV: -# -# Enabling this option exposes VFIO capabilities containing hardware -# configuration for zPCI devices. This enables userspace (e.g. QEMU) -# to supply proper configuration values instead of hard-coded defaults -# for zPCI devices passed through via VFIO on s390. -# -# Say Y here. -# -# Symbol: VFIO_PCI_ZDEV [=y] -# Type : bool -# Defined at drivers/vfio/pci/Kconfig:49 -# Prompt: VFIO PCI ZPCI device CLP support -# Depends on: VFIO_PCI [=m] && S390 [=y] -# Location: -# -> Device Drivers -# -> VFIO Non-Privileged userspace driver framework (VFIO [=m]) -# -> VFIO support for PCI devices (VFIO_PCI [=m]) -# -# -# -CONFIG_VFIO_PCI_ZDEV=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/748 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv3 0/2] [redhat] New configs in drivers/vfio
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/748 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_VFIO_PCI_ZDEV: Enabling this option exposes VFIO capabilities containing hardware configuration for zPCI devices. This enables userspace (e.g. QEMU) to supply proper configuration values instead of hard-coded defaults for zPCI devices passed through via VFIO on s390. Say Y here. Symbol: VFIO_PCI_ZDEV [=y] Type : bool Defined at drivers/vfio/pci/Kconfig:49 Prompt: VFIO PCI ZPCI device CLP support Depends on: VFIO_PCI [=m] && S390 [=y] Location: -> Device Drivers -> VFIO Non-Privileged userspace driver framework (VFIO [=m]) -> VFIO support for PCI devices (VFIO_PCI [=m]) --- Cc: Alex Williamson Cc: Eric Auger Cc: rhvirt-patc...@redhat.com Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv2 0/2] [redhat] New configs in drivers/vfio
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/748 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_VFIO_PCI_ZDEV: Enabling this option exposes VFIO capabilities containing hardware configuration for zPCI devices. This enables userspace (e.g. QEMU) to supply proper configuration values instead of hard-coded defaults for zPCI devices passed through via VFIO on s390. Say Y here. Symbol: VFIO_PCI_ZDEV [=y] Type : bool Defined at drivers/vfio/pci/Kconfig:49 Prompt: VFIO PCI ZPCI device CLP support Depends on: VFIO_PCI [=m] && S390 [=y] Location: -> Device Drivers -> VFIO Non-Privileged userspace driver framework (VFIO [=m]) -> VFIO support for PCI devices (VFIO_PCI [=m]) --- Cc: Alex Williamson Cc: Eric Auger Cc: rhvirt-patc...@redhat.com Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv2 1/2] [redhat] New configs in drivers/vfio
From: Fedora Kernel Team [redhat] New configs in drivers/vfio 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_VFIO_PCI_ZDEV: Enabling this option exposes VFIO capabilities containing hardware configuration for zPCI devices. This enables userspace (e.g. QEMU) to supply proper configuration values instead of hard-coded defaults for zPCI devices passed through via VFIO on s390. Say Y here. Symbol: VFIO_PCI_ZDEV [=y] Type : bool Defined at drivers/vfio/pci/Kconfig:49 Prompt: VFIO PCI ZPCI device CLP support Depends on: VFIO_PCI [=m] && S390 [=y] Location: -> Device Drivers -> VFIO Non-Privileged userspace driver framework (VFIO [=m]) -> VFIO support for PCI devices (VFIO_PCI [=m]) --- Cc: Alex Williamson Cc: Eric Auger Cc: rhvirt-patc...@redhat.com Signed-off-by: Fedora Kernel Team diff a/redhat/configs/common/generic/CONFIG_VFIO_PCI_ZDEV b/redhat/configs/common/generic/CONFIG_VFIO_PCI_ZDEV --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_VFIO_PCI_ZDEV @@ -0,0 +1 @@ +CONFIG_VFIO_PCI_ZDEV=y diff a/redhat/configs/pending-common/generic/CONFIG_VFIO_PCI_ZDEV b/redhat/configs/pending-common/generic/CONFIG_VFIO_PCI_ZDEV --- a/redhat/configs/pending-common/generic/CONFIG_VFIO_PCI_ZDEV +++ /dev/null @@ -1,22 +0,0 @@ -# CONFIG_VFIO_PCI_ZDEV: -# -# Enabling this option exposes VFIO capabilities containing hardware -# configuration for zPCI devices. This enables userspace (e.g. QEMU) -# to supply proper configuration values instead of hard-coded defaults -# for zPCI devices passed through via VFIO on s390. -# -# Say Y here. -# -# Symbol: VFIO_PCI_ZDEV [=y] -# Type : bool -# Defined at drivers/vfio/pci/Kconfig:49 -# Prompt: VFIO PCI ZPCI device CLP support -# Depends on: VFIO_PCI [=m] && S390 [=y] -# Location: -# -> Device Drivers -# -> VFIO Non-Privileged userspace driver framework (VFIO [=m]) -# -> VFIO support for PCI devices (VFIO_PCI [=m]) -# -# -# -CONFIG_VFIO_PCI_ZDEV=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/748 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv4] [redhat] New configs in crypto/Kconfig
From: Fedora Kernel Team [redhat] New configs in crypto/Kconfig 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_CRYPTO_SM2: Generic implementation of the SM2 public key algorithm. It was published by State Encryption Management Bureau, China. as specified by OSCCA GM/T 0003.1-2012 -- 0003.5-2012. References: https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02 http://www.oscca.gov.cn/sca/xxgk/2010-12/17/content_1002386.shtml http://www.gmbz.org.cn/main/bzlb.html Symbol: CRYPTO_SM2 [=n] Type : tristate Defined at crypto/Kconfig:263 Prompt: SM2 algorithm Depends on: CRYPTO [=y] Location: -> Cryptographic API (CRYPTO [=y]) Selects: CRYPTO_SM3 [=n] && CRYPTO_AKCIPHER [=y] && CRYPTO_MANAGER [=y] && MPILIB [=y] && ASN1 [=y] --- CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE: Allow obsolete cryptographic algorithms to be selected that have already been phased out from internal use by the kernel, and are only useful for userspace clients that still rely on them. Symbol: CRYPTO_USER_API_ENABLE_OBSOLETE [=y] Type : bool Defined at crypto/Kconfig:1915 Prompt: Enable obsolete cryptographic algorithms for userspace Depends on: CRYPTO [=y] && CRYPTO_USER_API [=y] Location: -> Cryptographic API (CRYPTO [=y]) --- CONFIG_CRYPTO_USER_API_RNG_CAVP: This option enables extra API for CAVP testing via the user-space interface: resetting of DRBG entropy, and providing Additional Data. This should only be enabled for CAVP testing. You should say no unless you know what this is. Symbol: CRYPTO_USER_API_RNG_CAVP [=n] Type : bool Defined at crypto/Kconfig:1895 Prompt: Enable CAVP testing of DRBG Depends on: CRYPTO [=y] && CRYPTO_USER_API_RNG [=y] && CRYPTO_DRBG [=y] Location: -> Cryptographic API (CRYPTO [=y]) -> User-space interface for random number generator algorithms (CRYPTO_USER_API_RNG [=y]) --- Cc: Herbert Xu Cc: "David S. Miller" Cc: Ondrej Mosnacek Signed-off-by: Fedora Kernel Team diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_SM3 b/redhat/configs/ark/generic/CONFIG_CRYPTO_SM3 --- a/redhat/configs/ark/generic/CONFIG_CRYPTO_SM3 +++ /dev/null @@ -1 +0,0 @@ -# CONFIG_CRYPTO_SM3 is not set diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_SM4_ARM64_CE b/redhat/configs/ark/generic/CONFIG_CRYPTO_SM4_ARM64_CE --- a/redhat/configs/ark/generic/CONFIG_CRYPTO_SM4_ARM64_CE +++ /dev/null @@ -1 +0,0 @@ -CONFIG_CRYPTO_SM4_ARM64_CE=m diff a/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM3_ARM64_CE b/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM3_ARM64_CE --- a/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM3_ARM64_CE +++ /dev/null @@ -1 +0,0 @@ -# CONFIG_CRYPTO_SM3_ARM64_CE is not set diff a/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM4 b/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM4 --- a/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM4 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_CRYPTO_SM4=m diff a/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE b/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE --- /dev/null +++ b/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE @@ -0,0 +1 @@ +CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE=y diff a/redhat/configs/common/generic/CONFIG_CRYPTO_ANUBIS b/redhat/configs/common/generic/CONFIG_CRYPTO_ANUBIS --- a/redhat/configs/common/generic/CONFIG_CRYPTO_ANUBIS +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_ANUBIS @@ -1 +1 @@ -CONFIG_CRYPTO_ANUBIS=m +# CONFIG_CRYPTO_ANUBIS is not set diff a/redhat/configs/common/generic/CONFIG_CRYPTO_ARC4 b/redhat/configs/common/generic/CONFIG_CRYPTO_ARC4 --- a/redhat/configs/common/generic/CONFIG_CRYPTO_ARC4 +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_ARC4 @@ -1 +1 @@ -CONFIG_CRYPTO_ARC4=m +# CONFIG_CRYPTO_ARC4 is not set diff a/redhat/configs/common/generic/CONFIG_CRYPTO_KHAZAD b/redhat/configs/common/generic/CONFIG_CRYPTO_KHAZAD --- a/redhat/configs/common/generic/CONFIG_CRYPTO_KHAZAD +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_KHAZAD @@ -1 +1 @@ -CONFIG_CRYPTO_KHAZAD=m +# CONFIG_CRYPTO_KHAZAD is not set diff a/redhat/configs/common/generic/CONFIG_CRYPTO_SEED b/redhat/configs/common/generic/CONFIG_CRYPTO_SEED --- a/redhat/configs/common/generic/CONFIG_CRYPTO_SEED +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_SEED @@ -1 +1 @@ -CONFIG_CRYPTO_SEED=m +# CONFIG_CRYPTO_SEED is not set diff a/redhat/configs/common/generic/CONFIG_CRYPTO_SM2 b
[OS-BUILD PATCHv3] [redhat] New configs in crypto/Kconfig
From: Fedora Kernel Team [redhat] New configs in crypto/Kconfig 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_CRYPTO_SM2: Generic implementation of the SM2 public key algorithm. It was published by State Encryption Management Bureau, China. as specified by OSCCA GM/T 0003.1-2012 -- 0003.5-2012. References: https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02 http://www.oscca.gov.cn/sca/xxgk/2010-12/17/content_1002386.shtml http://www.gmbz.org.cn/main/bzlb.html Symbol: CRYPTO_SM2 [=n] Type : tristate Defined at crypto/Kconfig:263 Prompt: SM2 algorithm Depends on: CRYPTO [=y] Location: -> Cryptographic API (CRYPTO [=y]) Selects: CRYPTO_SM3 [=n] && CRYPTO_AKCIPHER [=y] && CRYPTO_MANAGER [=y] && MPILIB [=y] && ASN1 [=y] --- CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE: Allow obsolete cryptographic algorithms to be selected that have already been phased out from internal use by the kernel, and are only useful for userspace clients that still rely on them. Symbol: CRYPTO_USER_API_ENABLE_OBSOLETE [=y] Type : bool Defined at crypto/Kconfig:1915 Prompt: Enable obsolete cryptographic algorithms for userspace Depends on: CRYPTO [=y] && CRYPTO_USER_API [=y] Location: -> Cryptographic API (CRYPTO [=y]) --- CONFIG_CRYPTO_USER_API_RNG_CAVP: This option enables extra API for CAVP testing via the user-space interface: resetting of DRBG entropy, and providing Additional Data. This should only be enabled for CAVP testing. You should say no unless you know what this is. Symbol: CRYPTO_USER_API_RNG_CAVP [=n] Type : bool Defined at crypto/Kconfig:1895 Prompt: Enable CAVP testing of DRBG Depends on: CRYPTO [=y] && CRYPTO_USER_API_RNG [=y] && CRYPTO_DRBG [=y] Location: -> Cryptographic API (CRYPTO [=y]) -> User-space interface for random number generator algorithms (CRYPTO_USER_API_RNG [=y]) --- Cc: Herbert Xu Cc: "David S. Miller" Cc: Ondrej Mosnacek Signed-off-by: Fedora Kernel Team diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_SM3 b/redhat/configs/ark/generic/CONFIG_CRYPTO_SM3 --- a/redhat/configs/ark/generic/CONFIG_CRYPTO_SM3 +++ /dev/null @@ -1 +0,0 @@ -# CONFIG_CRYPTO_SM3 is not set diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_SM4_ARM64_CE b/redhat/configs/ark/generic/CONFIG_CRYPTO_SM4_ARM64_CE --- a/redhat/configs/ark/generic/CONFIG_CRYPTO_SM4_ARM64_CE +++ /dev/null @@ -1 +0,0 @@ -CONFIG_CRYPTO_SM4_ARM64_CE=m diff a/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM3_ARM64_CE b/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM3_ARM64_CE --- a/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM3_ARM64_CE +++ /dev/null @@ -1 +0,0 @@ -# CONFIG_CRYPTO_SM3_ARM64_CE is not set diff a/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM4 b/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM4 --- a/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM4 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_CRYPTO_SM4=m diff a/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE b/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE --- /dev/null +++ b/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE @@ -0,0 +1 @@ +CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE=y diff a/redhat/configs/common/generic/CONFIG_CRYPTO_ANUBIS b/redhat/configs/common/generic/CONFIG_CRYPTO_ANUBIS --- a/redhat/configs/common/generic/CONFIG_CRYPTO_ANUBIS +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_ANUBIS @@ -1 +1 @@ -CONFIG_CRYPTO_ANUBIS=m +# CONFIG_CRYPTO_ANUBIS is not set diff a/redhat/configs/common/generic/CONFIG_CRYPTO_ARC4 b/redhat/configs/common/generic/CONFIG_CRYPTO_ARC4 --- a/redhat/configs/common/generic/CONFIG_CRYPTO_ARC4 +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_ARC4 @@ -1 +1 @@ -CONFIG_CRYPTO_ARC4=m +# CONFIG_CRYPTO_ARC4 is not set diff a/redhat/configs/common/generic/CONFIG_CRYPTO_KHAZAD b/redhat/configs/common/generic/CONFIG_CRYPTO_KHAZAD --- a/redhat/configs/common/generic/CONFIG_CRYPTO_KHAZAD +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_KHAZAD @@ -1 +1 @@ -CONFIG_CRYPTO_KHAZAD=m +# CONFIG_CRYPTO_KHAZAD is not set diff a/redhat/configs/common/generic/CONFIG_CRYPTO_SEED b/redhat/configs/common/generic/CONFIG_CRYPTO_SEED --- a/redhat/configs/common/generic/CONFIG_CRYPTO_SEED +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_SEED @@ -1 +1 @@ -CONFIG_CRYPTO_SEED=m +# CONFIG_CRYPTO_SEED is not set diff a/redhat/configs/common/generic/CONFIG_CRYPTO_SM2 b
[OS-BUILD PATCHv2] [redhat] New configs in crypto/Kconfig
From: Fedora Kernel Team [redhat] New configs in crypto/Kconfig 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_CRYPTO_SM2: Generic implementation of the SM2 public key algorithm. It was published by State Encryption Management Bureau, China. as specified by OSCCA GM/T 0003.1-2012 -- 0003.5-2012. References: https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02 http://www.oscca.gov.cn/sca/xxgk/2010-12/17/content_1002386.shtml http://www.gmbz.org.cn/main/bzlb.html Symbol: CRYPTO_SM2 [=n] Type : tristate Defined at crypto/Kconfig:263 Prompt: SM2 algorithm Depends on: CRYPTO [=y] Location: -> Cryptographic API (CRYPTO [=y]) Selects: CRYPTO_SM3 [=n] && CRYPTO_AKCIPHER [=y] && CRYPTO_MANAGER [=y] && MPILIB [=y] && ASN1 [=y] --- CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE: Allow obsolete cryptographic algorithms to be selected that have already been phased out from internal use by the kernel, and are only useful for userspace clients that still rely on them. Symbol: CRYPTO_USER_API_ENABLE_OBSOLETE [=y] Type : bool Defined at crypto/Kconfig:1915 Prompt: Enable obsolete cryptographic algorithms for userspace Depends on: CRYPTO [=y] && CRYPTO_USER_API [=y] Location: -> Cryptographic API (CRYPTO [=y]) --- CONFIG_CRYPTO_USER_API_RNG_CAVP: This option enables extra API for CAVP testing via the user-space interface: resetting of DRBG entropy, and providing Additional Data. This should only be enabled for CAVP testing. You should say no unless you know what this is. Symbol: CRYPTO_USER_API_RNG_CAVP [=n] Type : bool Defined at crypto/Kconfig:1895 Prompt: Enable CAVP testing of DRBG Depends on: CRYPTO [=y] && CRYPTO_USER_API_RNG [=y] && CRYPTO_DRBG [=y] Location: -> Cryptographic API (CRYPTO [=y]) -> User-space interface for random number generator algorithms (CRYPTO_USER_API_RNG [=y]) --- Cc: Herbert Xu Cc: "David S. Miller" Cc: Ondrej Mosnacek Signed-off-by: Fedora Kernel Team diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_SM3 b/redhat/configs/ark/generic/CONFIG_CRYPTO_SM3 --- a/redhat/configs/ark/generic/CONFIG_CRYPTO_SM3 +++ /dev/null @@ -1 +0,0 @@ -# CONFIG_CRYPTO_SM3 is not set diff a/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM3_ARM64_CE b/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM3_ARM64_CE --- a/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM3_ARM64_CE +++ /dev/null @@ -1 +0,0 @@ -# CONFIG_CRYPTO_SM3_ARM64_CE is not set diff a/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM4 b/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM4 --- a/redhat/configs/ark/generic/arm/aarch64/CONFIG_CRYPTO_SM4 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_CRYPTO_SM4=m diff a/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE b/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE --- /dev/null +++ b/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE @@ -0,0 +1 @@ +CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE=y diff a/redhat/configs/common/generic/CONFIG_CRYPTO_ANUBIS b/redhat/configs/common/generic/CONFIG_CRYPTO_ANUBIS --- a/redhat/configs/common/generic/CONFIG_CRYPTO_ANUBIS +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_ANUBIS @@ -1 +1 @@ -CONFIG_CRYPTO_ANUBIS=m +# CONFIG_CRYPTO_ANUBIS is not set diff a/redhat/configs/common/generic/CONFIG_CRYPTO_ARC4 b/redhat/configs/common/generic/CONFIG_CRYPTO_ARC4 --- a/redhat/configs/common/generic/CONFIG_CRYPTO_ARC4 +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_ARC4 @@ -1 +1 @@ -CONFIG_CRYPTO_ARC4=m +# CONFIG_CRYPTO_ARC4 is not set diff a/redhat/configs/common/generic/CONFIG_CRYPTO_KHAZAD b/redhat/configs/common/generic/CONFIG_CRYPTO_KHAZAD --- a/redhat/configs/common/generic/CONFIG_CRYPTO_KHAZAD +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_KHAZAD @@ -1 +1 @@ -CONFIG_CRYPTO_KHAZAD=m +# CONFIG_CRYPTO_KHAZAD is not set diff a/redhat/configs/common/generic/CONFIG_CRYPTO_SEED b/redhat/configs/common/generic/CONFIG_CRYPTO_SEED --- a/redhat/configs/common/generic/CONFIG_CRYPTO_SEED +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_SEED @@ -1 +1 @@ -CONFIG_CRYPTO_SEED=m +# CONFIG_CRYPTO_SEED is not set diff a/redhat/configs/common/generic/CONFIG_CRYPTO_SM2 b/redhat/configs/common/generic/CONFIG_CRYPTO_SM2 --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_CRYPTO_SM2 @@ -0,0 +1 @@ +CONFIG_CRYPTO_SM2=m diff a/redhat/configs/fedora/generic/CONFIG_CRYPTO_SM3 b/redhat/configs/common/gene
[OS-BUILD PATCHv2] [redhat] New configs in lib/Kconfig.debug
From: Fedora Kernel Team [redhat] New configs in lib/Kconfig.debug 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_CSD_LOCK_WAIT_DEBUG: This option enables debug prints when CPUs are slow to respond to the smp_call_function*() IPI wrappers. These debug prints include the IPI handler function currently executing (if any) and relevant stack traces. Symbol: CSD_LOCK_WAIT_DEBUG [=n] Type : bool Defined at lib/Kconfig.debug:1380 Prompt: Debugging for csd_lock_wait(), called from smp_call_function*() Depends on: DEBUG_KERNEL [=y] && 64BIT [=y] Location: -> Kernel hacking -> Lock Debugging (spinlocks, mutexes, etc...) --- CONFIG_SCF_TORTURE_TEST: This option provides a kernel module that runs torture tests on the smp_call_function() family of primitives. The kernel module may be built after the fact on the running kernel to be tested, if desired. Symbol: SCF_TORTURE_TEST [=n] Type : tristate Defined at lib/Kconfig.debug:1370 Prompt: torture tests for smp_call_function*() Depends on: DEBUG_KERNEL [=y] Location: -> Kernel hacking -> Lock Debugging (spinlocks, mutexes, etc...) Selects: TORTURE_TEST [=n] --- Cc: Prarit Bhargava Signed-off-by: Fedora Kernel Team diff a/redhat/configs/common/debug/CONFIG_CSD_LOCK_WAIT_DEBUG b/redhat/configs/common/debug/CONFIG_CSD_LOCK_WAIT_DEBUG --- /dev/null +++ b/redhat/configs/common/debug/CONFIG_CSD_LOCK_WAIT_DEBUG @@ -0,0 +1 @@ +CONFIG_CSD_LOCK_WAIT_DEBUG=y diff a/redhat/configs/common/debug/CONFIG_SCF_TORTURE_TEST b/redhat/configs/common/debug/CONFIG_SCF_TORTURE_TEST --- /dev/null +++ b/redhat/configs/common/debug/CONFIG_SCF_TORTURE_TEST @@ -0,0 +1 @@ +CONFIG_SCF_TORTURE_TEST=y diff a/redhat/configs/pending-common/generic/CONFIG_CSD_LOCK_WAIT_DEBUG b/redhat/configs/pending-common/generic/CONFIG_CSD_LOCK_WAIT_DEBUG --- a/redhat/configs/pending-common/generic/CONFIG_CSD_LOCK_WAIT_DEBUG +++ /dev/null @@ -1,19 +0,0 @@ -# CONFIG_CSD_LOCK_WAIT_DEBUG: -# -# This option enables debug prints when CPUs are slow to respond -# to the smp_call_function*() IPI wrappers. These debug prints -# include the IPI handler function currently executing (if any) -# and relevant stack traces. -# -# Symbol: CSD_LOCK_WAIT_DEBUG [=n] -# Type : bool -# Defined at lib/Kconfig.debug:1380 -# Prompt: Debugging for csd_lock_wait(), called from smp_call_function*() -# Depends on: DEBUG_KERNEL [=y] && 64BIT [=y] -# Location: -# -> Kernel hacking -# -> Lock Debugging (spinlocks, mutexes, etc...) -# -# -# -# CONFIG_CSD_LOCK_WAIT_DEBUG is not set diff a/redhat/configs/pending-common/generic/CONFIG_SCF_TORTURE_TEST b/redhat/configs/pending-common/generic/CONFIG_SCF_TORTURE_TEST --- a/redhat/configs/pending-common/generic/CONFIG_SCF_TORTURE_TEST +++ /dev/null @@ -1,20 +0,0 @@ -# CONFIG_SCF_TORTURE_TEST: -# -# This option provides a kernel module that runs torture tests -# on the smp_call_function() family of primitives. The kernel -# module may be built after the fact on the running kernel to -# be tested, if desired. -# -# Symbol: SCF_TORTURE_TEST [=n] -# Type : tristate -# Defined at lib/Kconfig.debug:1370 -# Prompt: torture tests for smp_call_function*() -# Depends on: DEBUG_KERNEL [=y] -# Location: -# -> Kernel hacking -# -> Lock Debugging (spinlocks, mutexes, etc...) -# Selects: TORTURE_TEST [=n] -# -# -# -# CONFIG_SCF_TORTURE_TEST is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/740 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv2 2/2] Update CONFIG_VIRTIO_MEM
From: Patrick Talbert Update CONFIG_VIRTIO_MEM diff a/redhat/configs/common/generic/CONFIG_VIRTIO_MEM b/redhat/configs/common/generic/CONFIG_VIRTIO_MEM --- a/redhat/configs/common/generic/CONFIG_VIRTIO_MEM +++ b/redhat/configs/common/generic/CONFIG_VIRTIO_MEM @@ -1 +1 @@ -CONFIG_VIRTIO_MEM=m +# CONFIG_VIRTIO_MEM is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/454 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv2 1/2] [redhat] New configs in drivers/virtio
From: Fedora Kernel Team [redhat] New configs in drivers/virtio 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_VIRTIO_MEM: This driver provides access to virtio-mem paravirtualized memory devices, allowing to hotplug and hotunplug memory. This driver was only tested under x86-64, but should theoretically work on all architectures that support memory hotplug and hotremove. If unsure, say M. Symbol: VIRTIO_MEM [=m] Type : tristate Defined at drivers/virtio/Kconfig:81 Prompt: Virtio mem driver Depends on: VIRTIO_MENU [=y] && X86_64 [=y] && VIRTIO [=y] && MEMORY_HOTPLUG_SPARSE [=y] && MEMORY_HOTREMOVE [=y] Location: -> Device Drivers -> Virtio drivers (VIRTIO_MENU [=y]) Selects: CONTIG_ALLOC [=y] --- Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: rhvirt-patc...@redhat.com Signed-off-by: Fedora Kernel Team diff a/redhat/configs/common/generic/CONFIG_VIRTIO_MEM b/redhat/configs/common/generic/CONFIG_VIRTIO_MEM --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_VIRTIO_MEM @@ -0,0 +1 @@ +CONFIG_VIRTIO_MEM=m diff a/redhat/configs/pending-common/generic/CONFIG_VIRTIO_MEM b/redhat/configs/pending-common/generic/CONFIG_VIRTIO_MEM --- a/redhat/configs/pending-common/generic/CONFIG_VIRTIO_MEM +++ /dev/null @@ -1,23 +0,0 @@ -# CONFIG_VIRTIO_MEM: -# -# This driver provides access to virtio-mem paravirtualized memory -# devices, allowing to hotplug and hotunplug memory. -# -# This driver was only tested under x86-64, but should theoretically -# work on all architectures that support memory hotplug and hotremove. -# -# If unsure, say M. -# -# Symbol: VIRTIO_MEM [=m] -# Type : tristate -# Defined at drivers/virtio/Kconfig:81 -# Prompt: Virtio mem driver -# Depends on: VIRTIO_MENU [=y] && X86_64 [=y] && VIRTIO [=y] && MEMORY_HOTPLUG_SPARSE [=y] && MEMORY_HOTREMOVE [=y] -# Location: -# -> Device Drivers -# -> Virtio drivers (VIRTIO_MENU [=y]) -# Selects: CONTIG_ALLOC [=y] -# -# -# -CONFIG_VIRTIO_MEM=m -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/454 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv2 0/2] [redhat] New configs in drivers/virtio
From: Jeremy Cline on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/454 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_VIRTIO_MEM: This driver provides access to virtio-mem paravirtualized memory devices, allowing to hotplug and hotunplug memory. This driver was only tested under x86-64, but should theoretically work on all architectures that support memory hotplug and hotremove. If unsure, say M. Symbol: VIRTIO_MEM [=m] Type : tristate Defined at drivers/virtio/Kconfig:81 Prompt: Virtio mem driver Depends on: VIRTIO_MENU [=y] && X86_64 [=y] && VIRTIO [=y] && MEMORY_HOTPLUG_SPARSE [=y] && MEMORY_HOTREMOVE [=y] Location: -> Device Drivers -> Virtio drivers (VIRTIO_MENU [=y]) Selects: CONTIG_ALLOC [=y] --- Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: rhvirt-patc...@redhat.com Signed-off-by: Fedora Kernel Team ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Streamlining the ARK config process
On Mon, Jun 08, 2020 at 03:10:15PM -0400, Prarit Bhargava wrote: > On 6/8/20 2:58 PM, Jeremy Cline wrote: > > Hey folks, > > > > Seeing the merge window configs rolling in along with people starting to > > open GitLab merge requests rather than exclusively emailing patches, I > > have a suggestion to make everyone's lives a bit easier, especially with > > the configurations: > > > > Start making use of the "developer" role[0] in GitLab. I recommend > > reading over the permissions to get an idea of what's allowed, but the > > short of it is developers can't push to protected branches, so can't > > accidentally (or maliciously) change any of the important branches in > > the repository, but they *can* modify non-protected branches like the > > config branches[1], apply labels, and so on. > > > > Rather than having a script set the configs, then someone review them, > > > ^^^ I think this first step is important. It makes it so I don't have to look > at the CONFIGs myself. Is it possible to have the script set the config, then > have me checkout the branch, change it myself, then push? > Yes, sorry it wasn't clear. I think the workflow should be 1. Scripts make all the config merge requests for you. 2. As a reviewer, when a setting does not match your expectation do something like: a. git checkout -t upstream/configs/2020-06-08/drivers/usb b. vim redhat/configs/... c. git add -A d. git commit --amend # add a note about why it's being changed e. git push -f 3. Ack the merge request. - Jeremy > > > ask the maintainer to change it, then review it again, then have the > > maintainer merge it, you can just check out the config branch for the > > merge request, change it yourself, push it, and mark it ready (or get > > more reviews) for merging. This cuts down on a lot of back and forth so > > it'll save everyone time. > > > > [0] https://gitlab.com/help/user/permissions > > [1] > > https://gitlab.com/cki-project/kernel-ark/-/branches/all?utf8=%E2%9C%93&search=configs%2F > > > > - Jeremy > > ___ > > kernel mailing list -- kernel@lists.fedoraproject.org > > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > > > ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Streamlining the ARK config process
Hey folks, Seeing the merge window configs rolling in along with people starting to open GitLab merge requests rather than exclusively emailing patches, I have a suggestion to make everyone's lives a bit easier, especially with the configurations: Start making use of the "developer" role[0] in GitLab. I recommend reading over the permissions to get an idea of what's allowed, but the short of it is developers can't push to protected branches, so can't accidentally (or maliciously) change any of the important branches in the repository, but they *can* modify non-protected branches like the config branches[1], apply labels, and so on. Rather than having a script set the configs, then someone review them, ask the maintainer to change it, then review it again, then have the maintainer merge it, you can just check out the config branch for the merge request, change it yourself, push it, and mark it ready (or get more reviews) for merging. This cuts down on a lot of back and forth so it'll save everyone time. [0] https://gitlab.com/help/user/permissions [1] https://gitlab.com/cki-project/kernel-ark/-/branches/all?utf8=%E2%9C%93&search=configs%2F - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [ARK PATCH 0/20] Nvidia hdmi audio fixes
On Tue, May 26, 2020 at 10:35:56PM +0200, Jiri Benc wrote: > On Tue, 26 May 2020 16:10:41 -0400, Jeremy Cline wrote: > > Do you have an opinion on a reasonable limit? I don't know what Google's > > SMTP servers allow without rate limiting, but that probably also needs > > considering. > > What about starting with 30 and seeing where this leads us? > Okay, I've bumped it up to 30. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [ARK PATCH 0/20] Nvidia hdmi audio fixes
On Tue, May 26, 2020 at 08:55:37PM +0200, Jiri Benc wrote: > On Mon, 25 May 2020 08:20:16 -, GitLab Bridge on behalf of jwrdegoede > wrote: > > The patch series is too large to sent by email. > > Jeremy, 20 patches is not that many to send via email. What is the > current limit? > It's currently set to 10. I imagine I picked this since it was largely used to send out config merge requests which are only 1 commit each. Do you have an opinion on a reasonable limit? I don't know what Google's SMTP servers allow without rate limiting, but that probably also needs considering. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [OS-BUILD PATCH] Drop the static path configuration for the Sphinx docs
On Mon, May 18, 2020 at 04:42:59PM -0400, Don Zickus wrote:
> On Mon, May 18, 2020 at 07:42:26PM -, GitLab Bridge on behalf of
> jeremycline wrote:
> > From: Jeremy Cline
> >
> > There are no static files at this time. I don't know the first thing
> > about CSS and rely on my elders and betters to make the documentation
> > look presentable. Configuring a static directory also generates a Sphinx
> > warning when it isn't present (which it isn't on clean checkouts because
> > it's empty) so just remove it.
> >
> > Signed-off-by: Jeremy Cline
> > ---
> > redhat/docs/conf.py | 5 -
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/redhat/docs/conf.py b/redhat/docs/conf.py
> > index b5e60902cd65..d873a31d984d 100644
> > --- a/redhat/docs/conf.py
> > +++ b/redhat/docs/conf.py
> > @@ -40,8 +40,3 @@ html_theme_options = {
> > "show_related": True,
> > "sidebar_collapse": True,
> > }
> > -
> > -# Add any paths that contain custom static files (such as style sheets)
> > here,
> > -# relative to this directory. They are copied after the builtin static
> > files,
> > -# so a file named "default.css" will overwrite the builtin "default.css".
> > -html_static_path = ["_static"]
>
> I assume you will update the gitlab-ci.yml file in kernel-ark-ci next?
>
I've updated the CI[0] and it can be merged after this is accepted.
[0] https://gitlab.com/cki-project/kernel-ark-ci/-/merge_requests/2
> Acked-by: Don Zickus
>
> > --
> > 2.26.2
> > ___
> > kernel mailing list -- kernel@lists.fedoraproject.org
> > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
>
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [ARK PATCH 0/2] x86: Fix compile issues with rh_check_supported()
Sorry for the noise folks, there's a couple bugs in the comment bridge. I've disabled it for the moment. On Thu, May 14, 2020 at 08:42:50PM -, GitLab Bridge on behalf of ['author'] wrote: > From: Jeremy Cline on gitlab.com > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/362#note_342834569 > > stan commented via email: > ``` > On Thu, 14 May 2020 20:20:52 - > GitLab Bridge on behalf of dzickusrh wrote: > > > From: Don Zickus > > > > Upstream status: RHEL only > > > > The variable x86_hyper_type is hidden behind a macro and not available > > when guest mode is not config'd enabled. > > > > Update to use hypervisor_is_type() macro, available since > > Thanks for fixing this. > ``` ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: kernel-ark merge request 354
On Wed, May 13, 2020 at 04:24:54PM -0400, Prarit Bhargava wrote:
> Hey everyone,
>
> I spoke with dzickus about this and he suggested I reach out to the list to
> get
> an idea of how to fix this.
>
> I originally pushed a branch "osnamechange" to gitlab and created merge
> request
> 354. That patch, as discussed in the other thread, caused CKI to fail.
>
> jcline commented in 354 that I had to rebase and make changes to his new
> Sphinx
> documentation. So I did
>
> git fetch --all
> git pull
> git checkout osnamechange
> git reset --hard upstream/os-build
>
> git push -f g...@gitlab.com:prarit/kernel-ark.git osnamechange
>
> which logically made sense to me.
>
> The result of this is that I now have 193 identified patches in the merge
> request. It appears what has happened is that the reset pulled in all of the
> changes from upstream.
I believe GitLab is saying the branch included 193 new commits, which
IIRC was exactly how many commits you were behind os-build, so it's just
indicating what got pulled in from the rebase. If you look at the
commits tab of the merge request you'll see there are actually 0 new
commits compared to os-build.
>
> So I have some questions ;)
>
> 1. What did I do wrong wrt to the kernel-ark workflow?
I think you just lost your commit somehow.
> 2. How do undo what I did ;)?
Whenever I mangle something in git, I find git-reflog invaluable. You
can get back to your original state with:
git checkout osnamechange
git reset --hard 1b1d4554fc1b
>
> Since no one has reviewed the patch, I could just delete the branch and start
> over. I'd rather know what I did wrong so I can avoid doing it in the future.
>
Typically the way I do this is:
git fetch --all
git checkout osnamechange
# drop the -i if you want non-interactive
git rebase -i upstream/os-build
# optionally add -u to set upstream
git push -f
Another way to recover from your current situation would be to just
cherry-pick the old commit:
# Assumes osnamechange is still the same as upstream/os-build
git checkout osnamechange
git cherry-pick 1b1d4554fc1b7f76a690fe9255ad75609e9ffe25
# Fix it up as necessary and then:
git add -A
git commit --amend
git push -f
One note generally about Git{Lab,Hub}. Best practice is to not close
merge requests and then create new ones with identical content. It's
much clearer to force push your branch. Closing the merge request
signals that something significant has changed about what your doing and
all prior review/code history is no longer relevant.
- Jeremy
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: kernel-ark | Pipeline #145379201 has failed for osnamechange | 1b1d4554 in !354
On Wed, May 13, 2020 at 06:21:04PM +0200, Jiri Benc wrote: > On Wed, 13 May 2020 10:21:49 -0400, Jeremy Cline wrote: > > It's actually not CKI, just a few smoke tests (config validation, making > > sure the SRPM builds) run on the free Gitlab runners. It'd be great to > > get CKI to do build tests in the future, though. > > Okay, thanks for correcting me. > > > Having the bridge wait for CI is configurable and I think it's best to > > just turn it off. It was most useful back when I was the only one making > > merge requests so I didn't spam the list with changes that were broken > > anyway. > > Sounds good. I agree that it should be turned off. It will create less > confusion. Could you do it, please? > > Thanks! It should, in theory, now email patches immediately without waiting for a CI result. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: kernel-ark | Pipeline #145379201 has failed for osnamechange | 1b1d4554 in !354
On Wed, May 13, 2020 at 01:57:31PM +0200, Jiri Benc wrote: > On Wed, 13 May 2020 07:22:45 -0400, Prarit Bhargava wrote: > > IOW this is a chicken-and-egg problem and I'm not sure how get around it. > > In other words, patches are sent to the list only after they pass CKI? > That's unexpected, though I can see that it could make sense. > > However, in that case, we need something that ensures that patches that > have not been sent to the list are never applied. I can imagine that a > CKI outage might make all Gitlab merge requests tagged as failed CI, > which would be overriden by the package maintainer in good faith to > unblock the development. But that would mean that many reviewers did > not have a chance to see the patches. We need to ensure this can't > happen. > It's actually not CKI, just a few smoke tests (config validation, making sure the SRPM builds) run on the free Gitlab runners. It'd be great to get CKI to do build tests in the future, though. Having the bridge wait for CI is configurable and I think it's best to just turn it off. It was most useful back when I was the only one making merge requests so I didn't spam the list with changes that were broken anyway. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Fwd: kernel-ark | Pipeline #145379201 has failed for osnamechange | 1b1d4554 in !354
On Tue, May 12, 2020 at 08:19:09PM -0400, Prarit Bhargava wrote: > jforbes, > > My patch in merge request 354 changes the names of makefile targets from rh-* > to > dist-* which will obviously cause the failures in the tests below. It looks > like I would have to also change the test code but cannot find a git repo for > it. Any idea where it is and is there a way to push both changes to the > kernel > and tests simultaneously? > > If that can't be done I guess I could commit a change that adds the dist-* > targets while keeping the rh-* targets, change the tests to use the dist-* > targets, and then another kernel change to remove the rh-* targets. Would > that > work? > So typically in GitLab the CI definition is stored in the branch in ".gitlab-ci.yml" (although this is configurable). If you look at the one in ARK's os-build branch[0], you'll notice it doesn't have much in it beyond a comment explaining why there's not much in it. The repository you're looking for is https://gitlab.com/cki-project/kernel-ark-ci/. One of the downsides to this approach is atomically changing the CI and the code under test isn't do-able. Perhaps in the future when the CI jobs aren't changing so frequently they can be maintained in the os-build and ark-patches branches without hitting many merge conflicts, or someone can write a job to keep the two in sync automatically. [0] https://gitlab.com/cki-project/kernel-ark/-/blob/os-build/.gitlab-ci.yml - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Stepping down as Fedora kernel maintainer
Hi folks, I'm moving on to other things at Red Hat, so I'm stepping down as a kernel maintainer. I'm not going very far and I'll still be involved in Fedora generally, so you'll still see me around (especially for the next few weeks as we complete the transition to the new kernel work- flow). I leave you in the very capable hands of Justin, who I'd like to thank for putting up with me these last few years. Regards, Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [OS-BUILD PATCH] Introduce a Sphinx documentation project
On Thu, May 07, 2020 at 07:34:13PM -, GitLab Bridge on behalf of jeremycline wrote: > From: Jeremy Cline > > Although the GitLab wiki is pretty nice for getting started, it doesn't > offer a great way for folks to contribute or provide reviews for > changes. Convert the current Wiki to RST and build it with Sphinx. This > should be nearly identical to the content of the wiki with the exception > of a new section on contributing to the documentation. > > When this is accepted, a new CI job can be added to automatically lint, > build, and host the Sphinx documentation on GitLab pages[0]. > > [0] https://docs.gitlab.com/ee/user/project/pages/ > Alright I've merged this and set up the CI jobs to build and deploy it. You can browse the docs at https://cki-project.gitlab.io/kernel-ark/. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [OS-BUILD PATCHv3] Add git config hook
On Wed, May 06, 2020 at 09:44:55AM -0400, Don Zickus wrote: > On Wed, May 06, 2020 at 01:45:34PM +0200, Jiri Benc wrote: > > On Wed, 6 May 2020 07:37:35 -0400, Prarit Bhargava wrote: > > > Good idea and I think it would be a smart thing to do. > > > > I generally agree but I don't think "ark" is the best option. The > > kernels are used for Fedora, too, and they will be used for RHEL. We > > should find a prefix that works for all of those kernels/distros. > > I was trying to think of something but I could not find anything > > suitable. It should be short (rules out "downstream") and easily > > remembered (rules out abbreviations for "downstream"). > > I had the same opinion. As we migrated the redhat/ over directly from RHEL, > it is very much polluted with RHELisms. I am happy to clean up the > RHELisms, I would like to use a generic term that covers > Fedora/CentOS-stream/RHEL/ARK. > > I had thoughts of using 'distro' and using that as a generic framework to > push upstream for other distros to plug into, but I never fully flushed out > that idea (ie s/redhat\//distro\//;s/rh-/distro-/). > > Though 'distro' is a tad cumbersome. 'os' may work as it is short enough > (using Prarit's suggestion) but is it intuitively descriptive enough? > 'dist'? I like the shortness of os, but as you say it's not super descriptive. I don't have strong feelings either way, though. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Fedora kernel workflow feedback
On Tue, Apr 21, 2020 at 05:23:47PM +0200, Thorsten Leemhuis wrote: > Lo! > > Am 20.04.20 um 16:41 schrieb Jeremy Cline: > > On Fri, Apr 17, 2020 at 10:06:02PM +0200, Thorsten Leemhuis wrote: > >> Am 17.04.20 um 20:55 schrieb Don Zickus: > > […] > >>> Is there any other large concern with the new workflow? > >> The more I think about this the more I dislike that we are not using > >> official, pristine tarballs anymore. This "Source0 is a tarball > >> generated from a git tree maintained outside of the Fedora infra and > >> patched with buildscripts" IMHO violates the intention of the SourceURL > >> part of the Fedora Packaging Guidelines that was put in place for good > >> reasons (by both red hat and community contributors): > >> https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ > > > > It sounds like maybe there's confusion about what the new tarball > > contains. > > Yes, there… > > > The tarballs that are generated and checked into dist-git contain no > > Fedora modifications and are directly from a commit or tag Linus's git > > tree generated with git-archive[0]. > > …indeed was. I apologize for getting this wrong. Just one suggestion in > that case: > > > The only thing that changed is > > before we took the latest tagged release, then applied an rc patch from > > upstream if available, then the snapshot from that week's development as > > a patch generated on the maintainer's machine, then applied > > Fedora-specific patches. Now we just git-archive Linus's master branch > > for the day. > > Can't we make that clearer by using something like this? > > Source0: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-ae83d0b416db002fe95601e7f97f64b59514d936.tar.gz > > That was for 5.7-rc2 and makes it obvious where I can download this from > if I do not trust the contents of the SRPM. And/or a comment right > before the Source0 line that explains the situation for ordinary people > might be good enough (yes, there is one, but it's hard to understand). > I lean towards a clearer comment. If we change the actual Source0 we have to stop xz-compressing the tarball and change the naming scheme to line up with the URL naming format. > > We can download the tarball (created by git-archive on a signed tag) > > from kernel.org instead of running git-archive on a signed tag > > ourselves if that will really help people sleep at night, but we'll > > still be slapping unsigned snapshots on top of that so it's not clear to > > me that we'll be gaining much. > > Yeah, you definitely have a point for rawhide. But once this scheme is > used for stable releases it's a bit different, as there the base will > normally have signed tag. > We've not actually got any machinery for stable releases yet so I think we can take that into account when we do that. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Fedora kernel workflow feedback
On Fri, Apr 17, 2020 at 10:06:02PM +0200, Thorsten Leemhuis wrote: > Hi Don! > > Am 17.04.20 um 20:55 schrieb Don Zickus: > > > > I know as Jeremy and Justin have rolled out changes recently there have been > > > concerns over technical and non-technical issues. While they are happy to > > > make various tweaks to the workflow that might have broken during the > > > conversion, I am asking for some of the bigger concerns, folks reach out to > > > me. > > FWIW from the perspective of someone that deals with kernel.spec in his > spare time occasionally I think the conversation worked mostly well. Thx > for that. A bit of fine tuning might be needed here and there, but well, > that's often the case in situations like this :-D > > > I am sure there are pieces we overlooked in our attempt to change the > > workflow and over the next few months we will try to address what makes > > sense. I just ask folks to redirect their concerns to me and work with us > > to get them resolved. > > > > The two concerns I am aware that need addressing are: > > * broken out patches > > Which is already in the works (thx again Jeremy!) > > > * handle drive-by users who know dist-git by not the source git tree > > A few additional comments in the spec file and the readme that Jeremy > proposed will take care of most of it afaics. And one more thing, see > next part of this reply. > > > Is there any other large concern with the new workflow? > > The more I think about this the more I dislike that we are not using > official, pristine tarballs anymore. This "Source0 is a tarball > generated from a git tree maintained outside of the Fedora infra and > patched with buildscripts" IMHO violates the intention of the SourceURL > part of the Fedora Packaging Guidelines that was put in place for good > reasons (by both red hat and community contributors): > https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ > It sounds like maybe there's confusion about what the new tarball contains. The tarballs that are generated and checked into dist-git contain no Fedora modifications and are directly from a commit or tag Linus's git tree generated with git-archive[0]. The only thing that changed is before we took the latest tagged release, then applied an rc patch from upstream if available, then the snapshot from that week's development as a patch generated on the maintainer's machine, then applied Fedora-specific patches. Now we just git-archive Linus's master branch for the day. We can download the tarball (created by git-archive on a signed tag) from kernel.org instead of running git-archive on a signed tag ourselves if that will really help people sleep at night, but we'll still be slapping unsigned snapshots on top of that so it's not clear to me that we'll be gaining much. [0] https://gitlab.com/cki-project/kernel-ark/-/blob/internal/redhat/scripts/create-tarball.sh - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Thu, 2020-04-16 at 08:34 +0200, Thorsten Leemhuis wrote:
> Am 15.04.20 um 15:41 schrieb Jeremy Cline:
> > On Wed, 2020-04-15 at 11:31 +0200, Thorsten Leemhuis wrote:
> > > Am 15.04.20 um 00:37 schrieb Jeremy Cline:
> > > > On Tue, 2020-04-07 at 15:33 +, Jeremy Cline wrote:
> > > > > On Wed, 2020-03-11 at 16:40 +, Jeremy Cline wrote:
> > > There is one thing I really dislike about the scheme (one it
> > > didn't
> > > notice when I took a brief look at it weeks ago; sorry): There
> > > are no
> > > individual patches anymore in dist-git/the srpm and that afaics
> > > violates
> > > the packaging guidelines.
> > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches
> > > […]
> > > So you you maybe change the scheme so individual patch files land
> > > in
> > > the
> > > src.rpm?
> > I'll look into how simple it is to change.
>
> Thx. Until then or in general: If you have a minute it IMHO would be
> really nice to have a comment in the spec file that…
>
> > It's easy to see in the
> > source tree, though, just look at the "ark-patches" branch.
>
> …wound explain this with a link to the git repo. Then maintainers
> from
> other distros or interested people that look in dist-git or the
> src.rpm
> known where to look for patches.
>
> And BTW: I wouldn't call that "easy". Simply browsing to
> https://src.fedoraproject.org/rpms/kernel/tree/f32 and looking for
> files
> that end with .patch is way easier, even if you know your way around
> with git. And if you want to take a closer look you don't have to
> clone
> only a small git repo instead of a really big fat one…
>
> > > P.S.: The "--with-vanilla" build option afaics doesn't work
> > > anymore,
> > > as
> > > patch-%{rpmversion}-redhat.patch and linux-kernel-test.patch are
> > > always
> > > applied.
> >
> > I'll see about that as well.
>
> Great, thx.
>
> > Note that if you want a vanilla SRPM it's
> > easy from the source tree:
> >
> > $ git checkout master
> > $ git merge internal
> > $ sed -i 's/=13/=11/g'
> > redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDE
> > R
> > $ make rh-srpm
>
> What kind of sorcery is that? ;-) Well, I guess I'll understand if I
> dig
> deeper into the kernel-ark documentation...
The short story is internal is the (poorly named) branch that contains
the config and build scripts. Fedora ships a patch that changes
CONFIG_FORCE_MAX_ZONEORDER default so it's invalid if you prep the
kernel without it. It might be best to not check configurations for
completeness and validity by default.
>
> This BTW might be the biggest problem with the whole new approach:
> It's
> not really obvious and a bit hard to understand. Yes, there are is
> lots
> of documentation in kernel-ark project, but if you are used to RPM or
> DEB packages and just want to peek into the Fedora kernel SRPM (say
> you
> have a kernel problem you want to track down and fix) then you might
> quickly feel lost, as there seems to be a lot of magic you have to
> learn
> for an otherwise small task. I know that this magic is supposed to
> make
> the kernel maintainers life easier, but it makes things a lot harder
> for
> other people that thus might give up instead of helping you. That's
> IMHO
> one of the reasons why the Fedora Packaging Committee put the rules
> in
> place I mentioned. Maybe a few more comments in the spec file or a
> document with a quickstart for this use case could help a lot.
>
I've proposed a readme[0] and something to break the patches out for
those who prefer dist-git[1].
There's also a fix for the buildid reordering[2] and the moving of
files around that breaks multiple preps[3].
I'm happy to make improvements and make this as easy as possible. It's
not perfect to start out and I apologize to anyone who's been
inconvenienced by that changes.
[0] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/303
[1] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/315
[2] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/296
[3] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/300
> > However, if you want to continue building from the dist-git, the
> > patch
> > is ignored if it's empty so doing
> >
> > $ truncate -s 0 patch-*-redhat.patch
> >
> > will also give you a vanilla build.
>
> Ahh, good to know.
>
> Thx for replying and looking into this,
>
Given this are do you still want a --with-vanilla option?
- Jeremy
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Thu, 2020-04-16 at 13:10 +0200, Nicolas Chauvet wrote: > Le mer. 15 avr. 2020 à 13:34, Josh Boyer > a écrit : > > On Wed, Apr 15, 2020 at 5:32 AM Thorsten Leemhuis < > > fed...@leemhuis.info> wrote: > ... > > > > There is one thing I really dislike about the scheme (one it > > > didn't > > > notice when I took a brief look at it weeks ago; sorry): There > > > are no > > > individual patches anymore in dist-git/the srpm and that afaics > > > violates > > > the packaging guidelines. > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches > > > > > > ``` > > > The files MUST then be checked into the Fedora Package revision > > > control > > > system […]. Storing the files in this way allows people to use > > > standard > > > tools to visualize the changes between revisions of the files and > > > track > > > additions and removals without a layer of indirection […]. > > > ``` > > > There are other rules in the patch section that afaics are > > > violated. > > > Were those violation discussed and blessed by the > > > Fedora Packaging Committee or FESCo? > > > > I don't think the split out patches "rule" is being violated here. > > They changed the source tarball to one generated from the git tree > > and > > they don't have any patches at the dist-git level at all. Several > > other packages in Fedora already do this, such as anaconda. > > So it means should one single line patch should be changed, you need > to re-upload a 100M tarball to the fedora lookaside cache? > I understand the benefit to have an upstream source tree as a primary > origin for kernel patch development. But what is the reason behind > this process in particular ? > > It would have been easier to only generate a full fedora diff against > the original upstream tree (using a commit-id that can also be > generated with gitlab with A PR). > Like how I expect it's done with the patch-5.7.0-redhat.patch. > > Then keep using the original upstream tarballs. (linux-M.tar.xz and > patch-M-m.xz) > I'm sure that in some cases, (minor patch update) there is even not > have to change the fedora diff. > Yes, it's a bit inefficient. I brought this up on the infrastructure list ([RFC] Optionally using git repositories instead of the lookaside cache), but people didn't seem concerned about the storage requirement. I am not particularly inspired to develop a bunch of scripts to work around the fact that we're not using git to store source code. If someone else wants to fix up the kernel build scripts I'm fine with that, although it seems to me that it's fixing the problem in the wrong place. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Issue with booting on latest kernels (EFI_DISABLE_PCI_DMA related)
On Wed, 2020-04-15 at 18:50 +0200, Igor Gnatenko wrote: > Hello, > > I have ThinkPad T480s and after latest kernel upgrades on Rawhide I > see something like: > > ``` > exit_boot() failed! > efi_main() failed! > ``` > > Right after grub and then system reboots. > > I found on the internet that passing `efi=no_disable_early_pci_dma` > could help and it actually did! > > Anybody else saw this issue? Any ideas if this could be worked around > in Fedora kernel? > > https://bugzilla.kernel.org/show_bug.cgi?id=206789 What's the kernel NVR? CONFIG_EFI_DISABLE_PCI_DMA has been disabled since its arrival so this is pretty odd. > -- > -Igor Gnatenko > ___ > kernel mailing list -- kernel@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Wed, 2020-04-15 at 11:15 +0200, Thorsten Leemhuis wrote: > Am 15.04.20 um 04:24 schrieb Paul Moore: > > On Tue, Apr 14, 2020 at 9:52 PM Paul Moore > > wrote: > > > > There is another change in the kernel's specfile relating to where > > the > > %buildid is inserted into the version string. Previously the > > kernel > > NVR would look like this: > > > > kernel-5.6.0-0.rc7.git1.1.BUILDID.fc33.src.rpm > > > > ... but now it looks like this: > > > > kernel-5.7.0-0.rc1.20200414git8632e9b5645b.1.fc33.BUILDID.src.rpm > > > > Any chance you can change the specfile so that the %buildid comes > > before %dist as it did in the past? Should be straight-forward, I'll take care of that today. > > And how about making it a bit shorter? Until now I added > ".vanilla.knurd.1" for my vanilla builds > (https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories ), but > doing > that now exceeds the 64 char limit now and thus results in build > error. > No big deal, I can remove the ".knurd", but I liked the old way more, > as > that made it more obvious *what* kind of kernel this is and *who* > built it. > > And is the "2020" really that important when we have 5.7-rc1 already? > How about changing "20200414git" to "0414g" and get something like > this > (saves 7 chars): > > kernel-5.7.0-0.rc1.0414g8632e9b5645b.1.fc33.BUILDID.src.rpm > > Anyway, I don't care to much, just a suggestion, no need for a big > bike > shedding debate. > So the current format follows the snapshot guidelines[0], but it *is* very long. While it's nice to follow the guidelines, the package hasn't been compliant before this so I suppose it's not terrible to bend the rules. I'm okay with this adjustment if folks are okay with treating the guidelines like... guidelines. [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Wed, 2020-04-15 at 11:31 +0200, Thorsten Leemhuis wrote:
> Am 15.04.20 um 00:37 schrieb Jeremy Cline:
> > On Tue, 2020-04-07 at 15:33 +0000, Jeremy Cline wrote:
> > > On Wed, 2020-03-11 at 16:40 +, Jeremy Cline wrote:
> > >
> > > Just a note folks, the plan is to do this starting next week
> > > after
> > > the close of the v5.7 merge window.
> >
> > Okay, this is now done. You may notice a number of stale options
> > made
> > their way back into the config files, it's on my to-do list to
> > clean
> > this up assuming there aren't any larger fires this week.
>
> There is one thing I really dislike about the scheme (one it didn't
> notice when I took a brief look at it weeks ago; sorry): There are no
> individual patches anymore in dist-git/the srpm and that afaics
> violates
> the packaging guidelines.
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches
>
> ```
> The files MUST then be checked into the Fedora Package revision
> control
> system […]. Storing the files in this way allows people to use
> standard
> tools to visualize the changes between revisions of the files and
> track
> additions and removals without a layer of indirection […].
> ```
> There are other rules in the patch section that afaics are violated.
> Were those violation discussed and blessed by the
> Fedora Packaging Committee or FESCo?
>
> I for one would dislike such an exception, because I sometimes look
> at
> kernel source packages from other dists and it is always annoying
> when I
> can't easily see individual patches. It also makes it way harder for
> users to remove one certain patch that Fedora applied for testing or
> other reasons.
>
> So you you maybe change the scheme so individual patch files land in
> the
> src.rpm?
I'll look into how simple it is to change. It's easy to see in the
source tree, though, just look at the "ark-patches" branch.
>
> Cu, knurd
>
> P.S.: The "--with-vanilla" build option afaics doesn't work anymore,
> as
> patch-%{rpmversion}-redhat.patch and linux-kernel-test.patch are
> always
> applied.
I'll see about that as well. Note that if you want a vanilla SRPM it's
easy from the source tree:
$ git checkout master
$ git merge internal
$ sed -i 's/=13/=11/g'
redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER
$ make rh-srpm
However, if you want to continue building from the dist-git, the patch
is ignored if it's empty so doing
$ truncate -s 0 patch-*-redhat.patch
will also give you a vanilla build.
- Jeremy
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Tue, 2020-04-14 at 21:13 -0400, Paul Moore wrote: > On Tue, Apr 14, 2020 at 6:37 PM Jeremy Cline > wrote: > > Okay, this is now done. You may notice a number of stale options > > made > > their way back into the config files, it's on my to-do list to > > clean > > this up assuming there aren't any larger fires this week. > > > > Please send any kernel changes as merge requests to the GitLab > > repository or as emails to this list. If you are one of the folks > > who > > has commit access to the dist-git and adds something there > > directly, > > I'll pull it into the source tree for you, but I *will* whine at > > you > > and I'm a world class whiner. > > My apologies if I missed a discussion on this earlier, but what is > the > process for building the source tarball for the kernel-headers > package? The old process does not seem to apply to the new build > process ... > The script did indeed get nuked (although obviously it's in the history forever). I haven't made a particular plan for this yet, but the script could either move into the kernel-headers package or the source tree. I'm inclined to move it into the source tree so the kernel-headers (and kernel-tools) packages can be generated from it as well. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Tue, 2020-04-07 at 15:33 +, Jeremy Cline wrote: > On Wed, 2020-03-11 at 16:40 +0000, Jeremy Cline wrote: > > Hi folks, > > > > This should come as no surprise to those who have been following > > the > > kernel list and/or saw Laura's Flock talk last summer, but there > > are > > some changes to the way the Fedora kernel is maintained coming in > > the > > next couple of weeks. > > > > For those folks who aren't committing directly to the kernel dist- > > git, > > this change won't really impact you, although contributing might be > > easier. > > > > We're planning to switch from maintaining the kernel directly in > > the > > dist-git to using a kernel source tree along with a set of scripts > > to > > turn the source tree into something that can be automatically > > checked > > into the dist-git. This means anything committed directly to the > > dist- > > git repository will get overwritten on the next update. > > > > The git repository is currently hosted at > > https://gitlab.com/cki-project/kernel-ark/. Documentation (still > > very > > rough) for common tasks is at > > https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a > > few > > outstanding merge requests to get the tree fully synced up with the > > current state of the dist-git repository, so if you decide to jump > > in > > and try things out, be aware things might not work. > > > > As part of this, we're going to start bridging merge requests to > > this > > list as emailed patch series for those who prefer email, and turn > > any > > emailed patches to the list into merge requests, so the list is > > going > > to get quite a bit more traffic. > > Just a note folks, the plan is to do this starting next week after > the > close of the v5.7 merge window. Okay, this is now done. You may notice a number of stale options made their way back into the config files, it's on my to-do list to clean this up assuming there aren't any larger fires this week. Please send any kernel changes as merge requests to the GitLab repository or as emails to this list. If you are one of the folks who has commit access to the dist-git and adds something there directly, I'll pull it into the source tree for you, but I *will* whine at you and I'm a world class whiner. Regards, Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Wed, 2020-03-11 at 16:40 +, Jeremy Cline wrote: > Hi folks, > > This should come as no surprise to those who have been following the > kernel list and/or saw Laura's Flock talk last summer, but there are > some changes to the way the Fedora kernel is maintained coming in the > next couple of weeks. > > For those folks who aren't committing directly to the kernel dist- > git, > this change won't really impact you, although contributing might be > easier. > > We're planning to switch from maintaining the kernel directly in the > dist-git to using a kernel source tree along with a set of scripts to > turn the source tree into something that can be automatically checked > into the dist-git. This means anything committed directly to the > dist- > git repository will get overwritten on the next update. > > The git repository is currently hosted at > https://gitlab.com/cki-project/kernel-ark/. Documentation (still very > rough) for common tasks is at > https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a > few > outstanding merge requests to get the tree fully synced up with the > current state of the dist-git repository, so if you decide to jump in > and try things out, be aware things might not work. > > As part of this, we're going to start bridging merge requests to this > list as emailed patch series for those who prefer email, and turn any > emailed patches to the list into merge requests, so the list is going > to get quite a bit more traffic. Just a note folks, the plan is to do this starting next week after the close of the v5.7 merge window. Regards, Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Backport ExFAT to Fedora 5.6 kernels?
On Sun, 2020-04-05 at 19:29 -0400, Neal Gompa wrote: > On Sun, Apr 5, 2020 at 6:00 PM Joel Wirāmu Pauling > wrote: > > Far more interested to make sure the AX200 wifi fixes land. I have > > two FC32 machines that suffer. > > > > That should probably be fixed with the 5.6.2 kernel landing, right? > As > far as I know, that's already fixed in the 5.6 tree. The availability > of exfat in Fedora 32 GA would open quite a few doors for cameras and > other equipment where media cards using exfat are quite common. > Well, support will arrive in updates with the 5.7 rebase. It would be nice to have, but the freeze is tomorrow, we try to keep feature backports to a minimum, and no one has actually done the work yet. All that to say I'm not sure this is the best way to invest our time. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Fri, 2020-03-13 at 07:07 -0400, Neal Gompa wrote: > On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera > wrote: > > > > > > - Original Message - > > > > > > On 3/12/20 10:57 AM, Bastien Nocera wrote: > > > > > > > > - Original Message - > > > > > > > > > The git tags are still signed by Linus. Does that cover your > > > > > concerns? > > > > > > > > Not really, no. I think that multiplying the intermediaries > > > > between > > > > kernel.org > > > > and the Fedora repos by adding gitlab.com in the middle might > > > > not be the > > > > best of ideas. > > > > > > > > If the Fedora security team is fine with it, I'm fine with it, > > > > and even if > > > > I > > > > understand the practical concerns (pagure not being up to par > > > > to deal with > > > > repos that size, and without a mail gateway support), I find it > > > > slightly > > > > concerning. > > > > > > > > > > I think this boils down to how much do you trust the kernel > > > maintainers. > > > Keep in mind that the existing model requires the kernel > > > maintainers > > > to manually pull down a tree and extract the tarball and then > > > upload. > > > You can probably trust them to not do anything malicious but > > > mistakes > > > can happen (source: I screwed up many times). It's good to be > > > concerned > > > about provenance as a threat model but I consider maintainers > > > screwing > > > up manual tasks to be a bigger threat model to Fedora kernel > > > security > > > so anything that moves towards automation is a benefit in my > > > eyes. > > > > For me, it's about how much we trust gitlab.com _in addition_ to > > trusting > > kernel.org and fedoraproject.org. I wouldn't be concerned at all if > > the new "in-between" tree was at either of those 2 locations. > > For what it's worth, while I agree, I doubt the kernel maintainers > will care about that. They clearly haven't cared given that the CKI > project does not run on what most in the project generally considers > "trusted infrastructure". > I'm not sure what your issue with CKI is, but that's beside the point. What exactly about the tarball coming from kernel.org makes you trust it? That's not a rhetorical question, I'm genuinely curious. Is it the x509 certificate they were issued? Is it that the tarballs are GPG- signed? > I also am personally not a fan of the "source-git" approach for > various reasons (including that it makes it *much* more difficult to > identify downstream vs upstream changes, more easily leading to > forks), but the kernel team actively contributes to upstream and our > current policy makes it incredibly difficult to have non-upstream > changes in the kernel, so I'm less worried there. > Currently we make a clone of Linus's tree and do a diff between master and the latest tag and then plop that into the lookaside cache. No individual commits, nothing. You know what happens if I'm working on a patch in that repository? Into the patch it goes, and good luck finding it among thousands of other changes. In the source tree, every commit is still broken out, figuring out what patches Fedora carries is a simple git command. It's *way* simpler to discover what patches are included in a build and why. Kind regards, Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Thu, 2020-03-12 at 10:11 -0400, Bastien Nocera wrote: > > - Original Message - > > Hi folks, > > > > This should come as no surprise to those who have been following > > the > > kernel list and/or saw Laura's Flock talk last summer, but there > > are > > some changes to the way the Fedora kernel is maintained coming in > > the > > next couple of weeks. > > > > For those folks who aren't committing directly to the kernel dist- > > git, > > this change won't really impact you, although contributing might be > > easier. > > > > We're planning to switch from maintaining the kernel directly in > > the > > dist-git to using a kernel source tree along with a set of scripts > > to > > turn the source tree into something that can be automatically > > checked > > into the dist-git. This means anything committed directly to the > > dist- > > git repository will get overwritten on the next update. > > > > The git repository is currently hosted at > > https://gitlab.com/cki-project/kernel-ark/. Documentation (still > > very > > rough) for common tasks is at > > https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a > > few > > outstanding merge requests to get the tree fully synced up with the > > current state of the dist-git repository, so if you decide to jump > > in > > and try things out, be aware things might not work. > > > > As part of this, we're going to start bridging merge requests to > > this > > list as emailed patch series for those who prefer email, and turn > > any > > emailed patches to the list into merge requests, so the list is > > going > > to get quite a bit more traffic. > > How do we ensure that this repo on gitlab.com is as trustworthy as > the > tarballs extracted from upstream kernel.org repos? > The git tags are still signed by Linus. Does that cover your concerns? - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
Hi Neal, On Thu, 2020-03-12 at 06:21 -0400, Neal Gompa wrote: > On Wed, Mar 11, 2020 at 12:41 PM Jeremy Cline > wrote: > > Hi folks, > > > > This should come as no surprise to those who have been following > > the > > kernel list and/or saw Laura's Flock talk last summer, but there > > are > > some changes to the way the Fedora kernel is maintained coming in > > the > > next couple of weeks. > > > > For those folks who aren't committing directly to the kernel dist- > > git, > > this change won't really impact you, although contributing might be > > easier. > > > > We're planning to switch from maintaining the kernel directly in > > the > > dist-git to using a kernel source tree along with a set of scripts > > to > > turn the source tree into something that can be automatically > > checked > > into the dist-git. This means anything committed directly to the > > dist- > > git repository will get overwritten on the next update. > > > > I don't think that's actually acceptable under Fedora guidelines, as > that violates the canonicity rule on the sources and spec[1]. > > Have you already worked out how to deal with that yet? Yes, I'll add something to the import script that checks to see if the prior commit is not from the import script. If it notices someone else committing to the dist-git it'll stop and require a maintainer handle it manually. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Upcoming Fedora kernel workflow changes
On Wed, 2020-03-11 at 12:58 -0400, Josh Boyer wrote: > On Wed, Mar 11, 2020 at 12:41 PM Jeremy Cline > wrote: > > Hi folks, > > > > This should come as no surprise to those who have been following > > the > > kernel list and/or saw Laura's Flock talk last summer, but there > > are > > some changes to the way the Fedora kernel is maintained coming in > > the > > next couple of weeks. > > > > For those folks who aren't committing directly to the kernel dist- > > git, > > this change won't really impact you, although contributing might be > > easier. > > > > We're planning to switch from maintaining the kernel directly in > > the > > dist-git to using a kernel source tree along with a set of scripts > > to > > turn the source tree into something that can be automatically > > checked > > into the dist-git. This means anything committed directly to the > > dist- > > git repository will get overwritten on the next update. > > > > The git repository is currently hosted at > > https://gitlab.com/cki-project/kernel-ark/. Documentation (still > > very > > rough) for common tasks is at > > https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a > > few > > outstanding merge requests to get the tree fully synced up with the > > current state of the dist-git repository, so if you decide to jump > > in > > and try things out, be aware things might not work. > > This looks like it will completely remove the need for > https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git > > Is that correct? (Please let it be correct.) > Eventually, yes. To start with we're just going to do Rawhide this way, but assuming things go well handling stable releases the same way should be straight-forward. > josh > > > As part of this, we're going to start bridging merge requests to > > this > > list as emailed patch series for those who prefer email, and turn > > any > > emailed patches to the list into merge requests, so the list is > > going > > to get quite a bit more traffic. > > > > Regards, > > Jeremy > > > > > > > > ___ > > kernel mailing list -- kernel@lists.fedoraproject.org > > To unsubscribe send an email to > > kernel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Upcoming Fedora kernel workflow changes
Hi folks, This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks. For those folks who aren't committing directly to the kernel dist-git, this change won't really impact you, although contributing might be easier. We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update. The git repository is currently hosted at https://gitlab.com/cki-project/kernel-ark/. Documentation (still very rough) for common tasks is at https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a few outstanding merge requests to get the tree fully synced up with the current state of the dist-git repository, so if you decide to jump in and try things out, be aware things might not work. As part of this, we're going to start bridging merge requests to this list as emailed patch series for those who prefer email, and turn any emailed patches to the list into merge requests, so the list is going to get quite a bit more traffic. Regards, Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 0/7] Backported eDP backlight fixes for i915 (README)
On Tue, 2020-03-10 at 14:07 -0400, Lyude Paul wrote: > Hi! These are the backported versions of the eDP backlight fixes for > i915 that Lenovo asked me to try getting into the Fedora kernel in > time > for beta. Note that these are pending upstream in intel's > drm-intel-next-queued tree, and will make it into the kernel come > next > merge window. > > NOTE!!! > While the exception for this was really only requested by Lenovo, > there's a couple of additional laptop panels that got added upstream > from Dell. Since the only extra work required to support them is just > adding some IDs into a quirk list I figured it'd be harmless to > include > here as well. Feel free to drop them if you don't think including > them > is a good idea. I've picked these up and they're in kernel-5.6.0-0.rc5.git0.2.fc32 (https://koji.fedoraproject.org/koji/buildinfo?buildID=1476218) Thanks! > > Upstream patch series: > * https://patchwork.freedesktop.org/series/69914/ > (one patch in ^ this series was reverted later, so it's been > omitted) > * https://patchwork.freedesktop.org/series/72991/ > > Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1811850 > > Lyude Paul (7): > drm/i915: Fix eDP DPCD aux max backlight calculations > drm/i915: Assume 100% brightness when not in DPCD control mode > drm/i915: Fix DPCD register order in > intel_dp_aux_enable_backlight() > drm/i915: Auto detect DPCD backlight support by default > drm/dp: Introduce EDID-based quirks > drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED > panel > drm/i915: Force DPCD backlight mode for some Dell CML 2020 panels > > drivers/gpu/drm/drm_dp_helper.c | 79 > drivers/gpu/drm/drm_dp_mst_topology.c | 3 +- > .../drm/i915/display/intel_display_types.h| 4 + > drivers/gpu/drm/i915/display/intel_dp.c | 11 +- > .../drm/i915/display/intel_dp_aux_backlight.c | 183 +--- > -- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +- > drivers/gpu/drm/i915/display/intel_psr.c | 2 +- > drivers/gpu/drm/i915/i915_params.c| 2 +- > drivers/gpu/drm/i915/i915_params.h| 2 +- > drivers/gpu/drm/i915/i915_utils.c | 1 - > drivers/gpu/drm/i915/i915_utils.h | 2 + > include/drm/drm_dp_helper.h | 21 +- > 12 files changed, 247 insertions(+), 65 deletions(-) > > -- > 2.24.1 > ___ > kernel mailing list -- kernel@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Intel SOF firmware
On Tue, 2020-03-03 at 16:09 +0100, Hans de Goede wrote: > Hi, > > On 3/3/20 3:29 PM, Peter Robinson wrote: > > > > > > Yes you are right, it should probably be something like the > > > > > > following: > > > > > > > > > > > > %ifarch x86_64 > > > > > > Requires: alsa-sof-firmware > > > > > > %endif > > > > > > > > > > > > (untested) > > > > > > > > > > Does anyone know, how the iwl*-firmware files are installed? > > > > > I cannot find any > > > > > dependency in kernel nor linux-firmware rpms. It's similar. > > > > > > > > It's done via comps. > > > > > > Hmm that does not really help here as the mean case we are trying > > > to > > > fix is F31 users upgrading from kernel 5.4 to 5.5. > > So thinking more about this, I guess we should only add the explicit > requires to the kernel package for F31 (and F30) and add it to comps > for F32+, this way F30 / F31 users will get the package through > the requires (and keep it on upgrade to F32+) and fresh F32 installs > will also get it this way. > > And this way we do not have to live forever with a Requires which > will > cause issues for efforts to make minimal installs as small as > possible. I think if we use Recommends dnf will install it by default, but it's not a dependency error if it's not installed[0]. [0] https://rpm.org/user_doc/dependencies.html - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: 5.6-rc3: changed COPYING can lead to a file conflict
On Mon, 2020-02-24 at 09:09 +0100, Thorsten Leemhuis wrote: > Hi! TWIMC just a quick heads up for the rc3 kernel rebase in rawhide, > as > I noticed a problem during my kernel vanilla builds that afaics will > hit > Fedora also and can easily be missed during the update afaics: > > The COPYING changed Friday night (see below), which will result in a > RPM > file conflict if not worked around (sorry, German error message, but > I > guess you'll get the idea): > > Datei /usr/share/licenses/kernel-core/COPYING-5.6.0 aus der > Installation von > kernel-core-5.6.0-0.rc3.git0.1.vanilla.knurd.1.fc33.x86_64 kollidiert > mit der Datei aus dem Paket kernel-core > > -5.6.0-0.rc2.git3.1.fc33.x86_64 > > CU, knurd Thanks for the heads-up. I've added the release field to the file which means that we won't have to deal with this problem again at the expense of users having a couple more copies of the file if using Rawhide kernels. Regards, Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] configs: clean up a few trivial editing mistakes
On Thu, 2020-01-30 at 22:09 +0100, Paul Bolle wrote: > Paul Bolle schreef op do 02-01-2020 om 10:38 [+0100]: > > Signed-off-by: Paul Bolle > > --- > > .../generic/x86/CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC~ | > > 1 - > > .../generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH | > > 1 - > > .../generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH~ | > > 1 - > > .../generic/x86/CONFIG_SND_SOC_SOF_HDA_ALWAYS_ENABLE_DMI_L1~ | > > 1 - > > 4 files changed, 4 deletions(-) > > delete mode 100644 > > configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_COD > > EC~ > > delete mode 100644 > > configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT56 > > 82_MACH~ > > delete mode 100644 > > configs/fedora/generic/x86/CONFIG_SND_SOC_SOF_HDA_ALWAYS_ENABLE_DMI > > _L1~ > > > > diff --git > > a/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_C > > ODEC~ > > b/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_C > > ODEC~ > > deleted file mode 100644 > > index 4181a1dd2e53.. > > --- > > a/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_C > > ODEC~ > > +++ /dev/null > > @@ -1 +0,0 @@ > > -CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC=n > > diff --git > > a/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT > > 5682_MACH > > b/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT > > 5682_MACH > > index c1358057017d..7cc6669fd1f8 100644 > > --- > > a/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT > > 5682_MACH > > +++ > > b/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT > > 5682_MACH > > @@ -1,2 +1 @@ > > CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH=m > > - > > diff --git > > a/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT > > 5682_MACH~ > > b/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT > > 5682_MACH~ > > deleted file mode 100644 > > index bad67ba0e62d.. > > --- > > a/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT > > 5682_MACH~ > > +++ /dev/null > > @@ -1 +0,0 @@ > > -# CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH is not set > > diff --git > > a/configs/fedora/generic/x86/CONFIG_SND_SOC_SOF_HDA_ALWAYS_ENABLE_D > > MI_L1~ > > b/configs/fedora/generic/x86/CONFIG_SND_SOC_SOF_HDA_ALWAYS_ENABLE_D > > MI_L1~ > > deleted file mode 100644 > > index df1d44aef2f2.. > > --- > > a/configs/fedora/generic/x86/CONFIG_SND_SOC_SOF_HDA_ALWAYS_ENABLE_D > > MI_L1~ > > +++ /dev/null > > @@ -1 +0,0 @@ > > -CONFIG_SND_SOC_SOF_HDA_ALWAYS_ENABLE_DMI_L1=n > > -- > > 2.21.0 > > These trivial issues still persist in origin/master. Could someone > please have > a look at this? > Apologies for the glacial response, applied to master. Thanks! - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: kernel-5.5.0-1.fc32.x86_64 DOA?
On Tue, 2020-02-04 at 15:10 -0600, Bruno Wolff III wrote: > On Tue, Jan 28, 2020 at 10:00:39 -0600, > Justin Forbes wrote: > > On Tue, Jan 28, 2020 at 12:35 AM Chris Murphy < > > li...@colorremedies.com> wrote: > > > Hi, > > > Two baremetal systems and one VM hang with kernel-5.5.0- > > > 1.fc32.x86_64 > > > right after GRUB menu entry selection/timeout for this kernel. > > > Black > > > screen, menu goes away, I see a white underscore, that's it. > > > Doesn't > > > recover. > > > > > > I put GRUB into debug mode and I can see the kernel file being > > > loaded > > > block by block off the media, but oh man something is off with > > > GRUB > > > because the text scroll is unbearably slow. So I just had to kill > > > it. > > > > > > Last working for me is kernel-5.5.0-0.rc6.git1.1.fc32.x86_64. > > > > > Yes, this seems to be entirely an issue of gcc10 produced kernels. > > Rebuilding it against F31 boots just fine. Still trying to figure > > out > > what the issue is. > > 5.6.0-0.rc0.git2.1.fc32.x86_64 is working for me. The issue is https://bugzilla.redhat.com/show_bug.cgi?id=1796780. I've temporarily disabled CONFIG_STACKPROTECTOR_STRONG on x86. Once I resolve the final build issues with armv7hl there should be a bootable Rawhide kernel again. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 0/4] Kconfig symbol cleanup for v5.5-rc1
On Wed, Jan 01, 2020 at 11:39:20PM +0100, Paul Bolle wrote: > Here's yet another Kconfig symbol cleanup, now for v5.5-rc1. (Yes, I > know we're already at v5.5-rc4 by now. I was busy with other things in > December.) > > This series is - as always - boring to review and hard to test > thoroughly. My tests where rather light. > > When submitting a very similar series for v5.4-rc1 I bragged about a way > to sort-of do this during regular builds. Silly me, because now I'm > still doing this by hand. Maybe someday I'll have something to show. > Don't hold your breath... > Sorry it took so long, but I've finally applied this to Rawhide, sans SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES change. Thanks again for keeping things tidy! > Paul Bolle (4): > configs: remove CONFIG_MTD_M25P80 > configs: remove CONFIG_CROSS_COMPILE_COMPAT_VDSO > configs: remove CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES > Kconfig symbol cleanup for v5.5-rc1 > > configs/fedora/debug/CONFIG_REFCOUNT_FULL| 1 - > configs/fedora/generic/CONFIG_CRYPTO_BLKCIPHER | 1 - > configs/fedora/generic/CONFIG_HEADERS_CHECK | 1 - > configs/fedora/generic/CONFIG_HEADER_TEST| 1 - > configs/fedora/generic/CONFIG_INFINIBAND_CXGB3 | 1 - > .../fedora/generic/CONFIG_INPUT_KXTJ9_POLLED_MODE| 1 - > configs/fedora/generic/CONFIG_KERNEL_HEADER_TEST | 1 - > configs/fedora/generic/CONFIG_PCIEASPM_DEBUG | 1 - > configs/fedora/generic/CONFIG_REFCOUNT_FULL | 1 - > .../fedora/generic/CONFIG_SND_HDA_INTEL_DETECT_DMIC | 1 - > configs/fedora/generic/arm/CONFIG_MTD_M25P80 | 1 - > configs/fedora/generic/arm/CONFIG_REFCOUNT_FULL | 1 - > .../arm/aarch64/CONFIG_CROSS_COMPILE_COMPAT_VDSO | 1 - > .../generic/arm/aarch64/CONFIG_QCOM_SDM845_LLCC | 1 - > .../fedora/generic/arm/armv7/CONFIG_INFINIBAND_CXGB3 | 1 - > .../generic/arm/armv7/armv7/CONFIG_PWM_TIPWMSS | 1 - > configs/fedora/generic/powerpc/CONFIG_SIMPLE_GPIO| 1 - > .../generic/powerpc/CONFIG_SND_HDA_INTEL_DETECT_DMIC | 1 - > configs/fedora/generic/s390x/CONFIG_INFINIBAND_CXGB3 | 1 - > configs/fedora/generic/x86/CONFIG_CRC_PMIC_OPREGION | 1 - > .../generic/x86/CONFIG_SND_HDA_INTEL_DETECT_DMIC | 1 - > .../CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES| 1 - > .../fedora/generic/x86/x86_64/CONFIG_CALGARY_IOMMU | 1 - > kernel-aarch64-debug-fedora.config | 12 > kernel-aarch64-fedora.config | 12 > kernel-armv7hl-debug-fedora.config | 11 --- > kernel-armv7hl-fedora.config | 11 --- > kernel-armv7hl-lpae-debug-fedora.config | 10 -- > kernel-armv7hl-lpae-fedora.config| 10 -- > kernel-i686-debug-fedora.config | 11 --- > kernel-i686-fedora.config| 11 --- > kernel-ppc64le-debug-fedora.config | 10 -- > kernel-ppc64le-fedora.config | 10 -- > kernel-s390x-debug-fedora.config | 9 - > kernel-s390x-fedora.config | 9 - > kernel-x86_64-debug-fedora.config| 12 > kernel-x86_64-fedora.config | 12 > 37 files changed, 173 deletions(-) > delete mode 100644 configs/fedora/debug/CONFIG_REFCOUNT_FULL > delete mode 100644 configs/fedora/generic/CONFIG_CRYPTO_BLKCIPHER > delete mode 100644 configs/fedora/generic/CONFIG_HEADERS_CHECK > delete mode 100644 configs/fedora/generic/CONFIG_HEADER_TEST > delete mode 100644 configs/fedora/generic/CONFIG_INFINIBAND_CXGB3 > delete mode 100644 configs/fedora/generic/CONFIG_INPUT_KXTJ9_POLLED_MODE > delete mode 100644 configs/fedora/generic/CONFIG_KERNEL_HEADER_TEST > delete mode 100644 configs/fedora/generic/CONFIG_PCIEASPM_DEBUG > delete mode 100644 configs/fedora/generic/CONFIG_REFCOUNT_FULL > delete mode 100644 configs/fedora/generic/CONFIG_SND_HDA_INTEL_DETECT_DMIC > delete mode 100644 configs/fedora/generic/arm/CONFIG_MTD_M25P80 > delete mode 100644 configs/fedora/generic/arm/CONFIG_REFCOUNT_FULL > delete mode 100644 > configs/fedora/generic/arm/aarch64/CONFIG_CROSS_COMPILE_COMPAT_VDSO > delete mode 100644 configs/fedora/generic/arm/aarch64/CONFIG_QCOM_SDM845_LLCC > delete mode 100644 configs/fedora/generic/arm/armv7/CONFIG_INFINIBAND_CXGB3 > delete mode 100644 configs/fedora/generic/arm/armv7/armv7/CONFIG_PWM_TIPWMSS > delete mode 100644 configs/fedora/generic/powerpc/CONFIG_SIMPLE_GPIO > delete mode 100644 > configs/fedora/generic/powerpc/CONFIG_SND_HDA_INTEL_DETECT_DMIC > delete mode 100644 configs/fedora/generic/s390x/CONFIG_INFINIBAND_CXGB3 > delete mode 100644 configs/fedora/generic/x86/CONFIG_CRC_PMIC_OPREGION > delete mode 100644 > configs/fedora/generic/x86/CONFIG_SND_HDA_INTE
Kernel 5.4 rebase plans
Hi folks, This week is the test week for 5.4 so next week, assuming all goes well, we'll be rebasing Fedora 31 to 5.4. You should expect to see 5.4 in updates testing for Fedora 31 sometime next week (I make no promises as to exactly when as I, like many other folks, will be on vacation). Fedora 30 should follow shortly afterwards. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Enabling vboxsf in Fedora 5.4+ kernels
On Tue, Nov 12, 2019 at 11:57:35AM +, Peter Robinson wrote: > On Tue, Nov 12, 2019 at 11:40 AM Hans de Goede wrote: > > > > Hi all, > > > > So vboxsf has finally landed upstream. I gave up getting it merged > > directly under fs/vboxsf since despite some fs-devel folks saying > > that it was as good as it is going to get (given the limitations > > of the API exposed by the host) it seems that the fs subsys maintainers > > did not have the time to take a look at it. > > > > So I've send it to GKH for merging under drivers/staging instead > > and somewhat to my surprise (not complaining) he send it in for > > this cycle. > > > > Since this upstream now; and despite being in staging has alread seen > > multiple reviews, I would like to get this enabled for the Fedora 5.4 > > kernels so that shared-folders will just work for users running Fedora > > as a VirtualBox guest. > > > > So unless there are any objections I'm going to flip the > > configs/fedora/generic/CONFIG_VBOXSF_FS file to m and enable this in rawhide > > soon. > > Apart from the fact it's already been enabled by Jeremy? :-P > > https://src.fedoraproject.org/rpms/kernel/c/2147ca93975deaf220619e9096e0b84d879febc9?branch=master I guess you can put me in the "no objections" camp. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
On Thu, Oct 24, 2019 at 09:41:22AM -0500, Jeremy Linton wrote: > Hi, > > On 8/22/19 11:36 AM, Laura Abbott wrote: > > On 8/22/19 8:58 AM, Prarit Bhargava wrote: > > > On 8/19/19 9:15 AM, Laura Abbott wrote: > > > > On 8/16/19 2:57 PM, Paul Bolle wrote: > > > > > Florian Weimer schreef op vr 16-08-2019 om 14:04 [+0200]: > > > > > > RHEL has a larger NR_CPU value, though. For example, it's 8192 on > > > > > > x86-64, while Fedora 31 has 1024. > > > > > > > > > > On the Fedora x86-64 debug builds it's 8192 again. Why's that? > > > > > > > > > > > > > > > Paul Bolle > > > > > > > > > > > > > That's the option for max cpus. We don't want to turn it on in all > > > > Fedora builds since it would use up more resources we probably don't > > > > actually need. Turning on for debugging in Fedora is okay though. > > > > RHEL is focused on larger footprints and makes the trade off to > > > > have it enabled all the time. > > > > > > > > > > I think I measured the impact of 8192 vs 512 (or 256?) a long time > > > ago and we > > > are talking about _k_ of memory. We should stick with what upstream > > > has at > > > 8192. It's easier to debug when we have the same value as the > > > default IMO. > > > > > > Having said that, it has been a long time since I had to debug a > > > NR_CPUS/nr_cpus > > > issue in the kernel. We're just not seeing bugs around the value > > > anymore. > > > > > > > I was going to ask about the actual impact of a larger number of CPUs. > > If it's > > actually only k of memory it's probably better to just set MAXCPUS all > > the time. > > Even the lowest end machines probably see more change when frameworks > > change. > > > > And yes, I also think that we've come a long way so NR_CPUS is less of > > an important > > option to optimize these days. I think I'll just submit another patch to > > just do > > the max cpus. > > > > Forgive me if you have already posted (didn't see it yet). > > Its probably a good idea to bump the aarch64 config at the same time. Some > aarch64 "desktop" machines is already at the 256 core limit currently in > use. > I've bumped aarch64 up to 4096, s390x up to 512, and powerpc up to 2048 in Rawhide and it'll be in the build after v5.4-rc6. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] configs: fix typo "CONFIG_DRM_TDFX=n"
On Fri, Oct 11, 2019 at 11:57:45PM +0200, Paul Bolle wrote: > Signed-off-by: Paul Bolle > --- > Eyeball tested only. Finger crossed! Applied, thanks. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 0/5] Kconfig symbol cleanup for v5.4-rc1
On Thu, Oct 10, 2019 at 07:38:50PM +0200, Paul Bolle wrote: > Jeremy Cline schreef op do 10-10-2019 om 17:07 [+]: > > These ended up not cleanly applying with git-am (I'm guessing going > > through the mailing list mauled them in some way I don't care to > > discover) and since I only got CCd on one of the patches I just mashed > > them together with git-apply. > > Or perhaps I messed up something while I was preparing the patches before > sending them out. > It looks to be the Fedora mailing list mangling things. Applying from the mailing list with --ignore-whitespace works and applying the patch that got Cc'd to my @redhat email works fine without it. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 0/5] Kconfig symbol cleanup for v5.4-rc1
On Thu, Oct 10, 2019 at 02:20:54PM +0200, Paul Bolle wrote: > Here's yet another Kconfig symbol cleanup, now for v5.4-rc1. > > This series is - as always - boring to review and hard to test > thoroughly. (I build-tested this on x86_64, but a sufficiently paranoid > tester would like to build-test on other arches too. I do not have > access to non-x86 hardware.) Sorry about that. > > Note that four symbols that were dropped in v5.4-rc1 (ie, > CONFIG_ARCH_IOP13XX, CONFIG_ARCH_IOP33X, CONFIG_ARCH_KS8695, and > CONFIG_ARCH_W90X900) were already removed by a recent patch by Peter. > Nice! > > Anyhow, working on this I thought of a way to sort-of do this during > regular builds. I hope to work on that before v5.5-rc1. Stay tuned! > These ended up not cleanly applying with git-am (I'm guessing going through the mailing list mauled them in some way I don't care to discover) and since I only got CCd on one of the patches I just mashed them together with git-apply. Sorry for undoing all the splitting up you did, but hopefully this is the last cycle any manual work needs to get done. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] re-enable HDA sound drivers on PPC
On Wed, Oct 09, 2019 at 12:21:34PM +0200, Dan Horák wrote: > --- > configs/fedora/generic/powerpc/CONFIG_SND_HDA_INTEL | 1 + > configs/fedora/generic/powerpc/CONFIG_SND_HDA_INTEL_DETECT_DMIC | 1 + > kernel-ppc64le-debug.config | 2 +- > kernel-ppc64le.config | 2 +- > 4 files changed, 4 insertions(+), 2 deletions(-) > create mode 100644 configs/fedora/generic/powerpc/CONFIG_SND_HDA_INTEL > create mode 100644 > configs/fedora/generic/powerpc/CONFIG_SND_HDA_INTEL_DETECT_DMIC > > diff --git a/configs/fedora/generic/powerpc/CONFIG_SND_HDA_INTEL > b/configs/fedora/generic/powerpc/CONFIG_SND_HDA_INTEL > new file mode 100644 > index 0..dfe74ea98 > --- /dev/null > +++ b/configs/fedora/generic/powerpc/CONFIG_SND_HDA_INTEL > @@ -0,0 +1 @@ > +CONFIG_SND_HDA_INTEL=m > diff --git a/configs/fedora/generic/powerpc/CONFIG_SND_HDA_INTEL_DETECT_DMIC > b/configs/fedora/generic/powerpc/CONFIG_SND_HDA_INTEL_DETECT_DMIC > new file mode 100644 > index 0..501f523b0 > --- /dev/null > +++ b/configs/fedora/generic/powerpc/CONFIG_SND_HDA_INTEL_DETECT_DMIC > @@ -0,0 +1 @@ > +# CONFIG_SND_HDA_INTEL_DETECT_DMIC is not set > diff --git a/kernel-ppc64le-debug.config b/kernel-ppc64le-debug.config > index 82585d81a..c85d5b83a 100644 > --- a/kernel-ppc64le-debug.config > +++ b/kernel-ppc64le-debug.config > @@ -4929,7 +4929,7 @@ CONFIG_SND_HDA_I915=y > CONFIG_SND_HDA_INPUT_BEEP_MODE=0 > CONFIG_SND_HDA_INPUT_BEEP=y > # CONFIG_SND_HDA_INTEL_DETECT_DMIC is not set > -# CONFIG_SND_HDA_INTEL is not set > +CONFIG_SND_HDA_INTEL=m > CONFIG_SND_HDA_PATCH_LOADER=y > CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 > CONFIG_SND_HDA_PREALLOC_SIZE=4096 > diff --git a/kernel-ppc64le.config b/kernel-ppc64le.config > index 0c7b7bcaf..52cd43193 100644 > --- a/kernel-ppc64le.config > +++ b/kernel-ppc64le.config > @@ -4907,7 +4907,7 @@ CONFIG_SND_HDA_I915=y > CONFIG_SND_HDA_INPUT_BEEP_MODE=0 > CONFIG_SND_HDA_INPUT_BEEP=y > # CONFIG_SND_HDA_INTEL_DETECT_DMIC is not set > -# CONFIG_SND_HDA_INTEL is not set > +CONFIG_SND_HDA_INTEL=m > CONFIG_SND_HDA_PATCH_LOADER=y > CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 > CONFIG_SND_HDA_PREALLOC_SIZE=4096 > -- > 2.21.0 Applied, thanks! ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 0/5] Kconfig symbol cleanup for v5.4-rc1
On Thu, Oct 10, 2019 at 03:56:09PM +0200, Paul Bolle wrote: > Jeremy Cline schreef op do 10-10-2019 om 09:31 [-0400]: > > On Thu, Oct 10, 2019 at 02:20:54PM +0200, Paul Bolle wrote: > > > Anyhow, working on this I thought of a way to sort-of do this during > > > regular builds. I hope to work on that before v5.5-rc1. Stay tuned! > > > > So I *also* have a vague plan for this (but have not had time to > > implement it). The short version of the plan is have a Python script > > that walks the kernel Kconfig tree and compares it to our config > > snippets to find configurations that no long exist in the kernel and at > > the same time find the new configurations and drop them into the correct > > arch directories with a default value and the help text. That way the > > job of rebasing is also much easier. > > > > How does that line up with your plan? > > My "sort-of" is your "vague"! > > My current thinking is that it's odd that we generate the .config files in > three steps. > > 1: the entire configs/fedora/generic/... tree: we update this tree by hand, > basically; > 2: the shipped kernel-*.config files: generated by build_configs.sh; > 3: the .config files generated by the upstream Kconfig plumbing. > > It would be much nicer if of all three would identical. (Which implies the > shipped kernel-*.config files would become superfluous.) And then we could > start by issuing warnings every time the configs/ tree and a generated .config > file get out of sync. (We already do this if we spot new Kconfig values in the > generated .config files. I think in process_configs.sh.) > > The hardest part is that current configs/ tree cheats. It makes > # CONFIG_FOO_BAR is not set > > also apply for the situation that CONFIG_FOO_BAR is invisible (or whatever the > proper Kconfig jargon is here). I need to play with my idea to see how > invisible Kconfig macros could be handled without cheating. Interesting... The idea of "just one place" is a good one. There's been some work on a maintenance approach where dist-git is all done automatically and maintainers just deal with the upstream tree[0] and there the situation is you just set it in the configs/ directory and that's it (because the shipped kernel-*.config files are generated and checked into the dist-git without human involvement. > > The next step might be something like your automation. That looks hard, > though! > There's a Python library, kconfiglib, that is a pure Python implementation of Kconfig. The problem is Kconfig seems to just be whatever the kernel Kconfig tool can handle so kconfiglib often breaks because of various small differences. I got started on Python bindings using CFFI so we can just use Kconfig directly from Python (I guess I could also just write the C code to do this, but ugh). Once I finish those it should be pretty simple to do all sorts of crazy config manipulations. If you're interested in working on the CFFI bindings I can throw what I have up on GitHub or something, but it's very much not functional at the moment. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] Enable CONFIG_EFI_TEST as a module (rhbz 1759325)
On Thu, Oct 10, 2019 at 02:59:39PM +0200, Paul Bolle wrote:
> Javier Martinez Canillas schreef op do 10-10-2019 om 13:38 [+0200]:
> > configs/fedora/generic/CONFIG_EFI_TEST| 2 +-
> > [...]
> > kernel-aarch64-debug.config | 2 +-
> > kernel-aarch64.config | 2 +-
> > kernel-armv7hl-debug.config | 2 +-
> > kernel-armv7hl-lpae-debug.config | 2 +-
> > kernel-armv7hl-lpae.config| 2 +-
> > kernel-armv7hl.config | 2 +-
> > kernel-i686-debug.config | 2 +-
> > kernel-i686.config| 2 +-
> > kernel-x86_64-debug.config| 2 +-
> > kernel-x86_64.config | 2 +-
>
> You enabled it globally ("generic") but no changes show up in the shipped
> .config files for ppc64le or in s390x. So you didn't run build_configs.sh, did
> you?
>
Not sure what other maintainers do, but I prefer to just run
build_configs.sh myself rather than get it as part of the patch. It
makes reviewing the patch easier.
Really it should be run pre-build automatically, and that might start
happening in the not-to-distant future.
> > --- a/configs/fedora/generic/CONFIG_EFI_TEST
> > +++ b/configs/fedora/generic/CONFIG_EFI_TEST
> > @@ -1 +1 @@
> > -# CONFIG_EFI_TEST is not set
> > +CONFIG_EFI_TEST=m
>
> If my grepping of the upstream tree is correct EFI is indeed not relevant for
> powerpc or s390. So I think you should not set this globally, but only for the
> other four arches (as you tried to do above, but incorrectly). I think it
> would be easiest to disable this in .../powerpc/CONFIG_EFI_TEST and
> ../s390x/CONFIG_EFI_TEST.
>
Indeed, and when I applied this I flipped it off for s390 and ppc.
Thanks for the review.
- Jeremy
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] Enable CONFIG_EFI_TEST as a module (rhbz 1759325)
On Thu, Oct 10, 2019 at 01:38:57PM +0200, Javier Martinez Canillas wrote: > The driver is needed for testing purposes, enable it on the architectures > where EFI is supported. Also, disallow access to the registered device if > the kernel is locked down. Applied, thanks.I did see the bugzilla, but got busy and lost it in the shuffle. Sorry about that. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 0/5] Kconfig symbol cleanup for v5.4-rc1
Hi, On Thu, Oct 10, 2019 at 02:20:54PM +0200, Paul Bolle wrote: > Here's yet another Kconfig symbol cleanup, now for v5.4-rc1. > > This series is - as always - boring to review and hard to test > thoroughly. (I build-tested this on x86_64, but a sufficiently paranoid > tester would like to build-test on other arches too. I do not have > access to non-x86 hardware.) Sorry about that. > No worries, thanks for the patch. > Note that four symbols that were dropped in v5.4-rc1 (ie, > CONFIG_ARCH_IOP13XX, CONFIG_ARCH_IOP33X, CONFIG_ARCH_KS8695, and > CONFIG_ARCH_W90X900) were already removed by a recent patch by Peter. > Nice! > > Anyhow, working on this I thought of a way to sort-of do this during > regular builds. I hope to work on that before v5.5-rc1. Stay tuned! So I *also* have a vague plan for this (but have not had time to implement it). The short version of the plan is have a Python script that walks the kernel Kconfig tree and compares it to our config snippets to find configurations that no long exist in the kernel and at the same time find the new configurations and drop them into the correct arch directories with a default value and the help text. That way the job of rebasing is also much easier. How does that line up with your plan? - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Bluetooth regression breaking BT connection for all 2.0 and older devices in 5.0.15+, 5.1.x and master
On Fri, Jun 14, 2019 at 11:18:24AM +0200, Hans de Goede wrote:
> Hi,
>
> On 10-06-19 15:36, Hans de Goede wrote:
> > Hi,
> >
> > On 10-06-19 15:31, Hans de Goede wrote:
> > > Hi All,
> > >
> > > First of all this is a known issue and it seems a fix is in the works,
> > > but what I do not understand is why the commit causing this has not
> > > simply been reverted until the fix is done, esp. for the 5.0.x
> > > stable series where this was introduced in 5.0.15.
> > >
> > > The problem I'm talking about is commit d5bb334a8e17 ("Bluetooth: Align
> > > minimum encryption key size for LE and BR/EDR connections"):
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d5bb334a8e171b262e48f378bd2096c0ea458265
> > > basically completely breaking all somewhat older (and some current cheap
> > > no-name) bluetooth devices:
> > >
> > > A revert of this was first proposed on May 22nd:
> > > https://lore.kernel.org/netdev/CA+E=qVfopSA90vG2Kkh+XzdYdNn=M-hJN_AptW=r+b5v3hb...@mail.gmail.com/T/
> > > We are 18 days further now and this problem still exists, including in the
> > > 5.0.15+ and 5.1.x stable kernels.
> > >
> > > A solution has been suggested:
> > > https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-mar...@holtmann.org/T/#u
> > > and at least the Fedora 5.1.4+ kernels now carry this as a temporary fix,
> > > but as of today I do not see a fix nor a revert in Torvald's tree yet and
> > > neither does there seem to be any fix in the 5.0.x and 5.1.x stable
> > > series.
> > >
> > > In the mean time we are getting a lot of bug reports about this:
> > > https://bugzilla.kernel.org/show_bug.cgi?id=203643
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1711468
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1713871
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1713980
> > >
> > > And some reporters:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1713871#c4
> > > Are indicating that the Fedora kernels with the workaround included
> > > still do not work...
> >
> > Given that things are still broken for some users, I suggest that
> > for Fedora we replace the workaround with a straight forward revert
> > of d5bb334a8e17 for now. Also the rawhide kernels are missing the
> > workaround, so those are currently broken regardless.
>
> Note since Torvald's mastter branch still does not have a fix for this,
> Greg has gone with a straight forward revert for all the stable series
> including 5.1.x .
>
> This means that the rawhide kernels are currently still broken, I
> suggest that we pick-up Greg's revert and add that as a downstream patch
> to the rawhide kernels for now.
>
> Greg's patch has not been pushed to the linux-stable repo yet,
> so I will forward it to kernel@lists.fedoraproject.org.
Thanks for the reminder, I've added the patch to Rawhide so it should be
in the next build. I included the revert in v5.1.9 (in updates-testing)
as well.
- Jeremy
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Bluetooth regression breaking BT connection for all 2.0 and older devices in 5.0.15+, 5.1.x and master
On Mon, Jun 10, 2019 at 03:36:50PM +0200, Hans de Goede wrote:
> Hi,
>
> On 10-06-19 15:31, Hans de Goede wrote:
> > Hi All,
> >
> > First of all this is a known issue and it seems a fix is in the works,
> > but what I do not understand is why the commit causing this has not
> > simply been reverted until the fix is done, esp. for the 5.0.x
> > stable series where this was introduced in 5.0.15.
> >
> > The problem I'm talking about is commit d5bb334a8e17 ("Bluetooth: Align
> > minimum encryption key size for LE and BR/EDR connections"):
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d5bb334a8e171b262e48f378bd2096c0ea458265
> > basically completely breaking all somewhat older (and some current cheap
> > no-name) bluetooth devices:
> >
> > A revert of this was first proposed on May 22nd:
> > https://lore.kernel.org/netdev/CA+E=qVfopSA90vG2Kkh+XzdYdNn=M-hJN_AptW=r+b5v3hb...@mail.gmail.com/T/
> > We are 18 days further now and this problem still exists, including in the
> > 5.0.15+ and 5.1.x stable kernels.
> >
> > A solution has been suggested:
> > https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-mar...@holtmann.org/T/#u
> > and at least the Fedora 5.1.4+ kernels now carry this as a temporary fix,
> > but as of today I do not see a fix nor a revert in Torvald's tree yet and
> > neither does there seem to be any fix in the 5.0.x and 5.1.x stable series.
> >
> > In the mean time we are getting a lot of bug reports about this:
> > https://bugzilla.kernel.org/show_bug.cgi?id=203643
> > https://bugzilla.redhat.com/show_bug.cgi?id=1711468
> > https://bugzilla.redhat.com/show_bug.cgi?id=1713871
> > https://bugzilla.redhat.com/show_bug.cgi?id=1713980
> >
> > And some reporters:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1713871#c4
> > Are indicating that the Fedora kernels with the workaround included
> > still do not work...
>
> Given that things are still broken for some users, I suggest that
> for Fedora we replace the workaround with a straight forward revert
> of d5bb334a8e17 for now. Also the rawhide kernels are missing the
> workaround, so those are currently broken regardless.
The v5.1.8 kernels are already done building so this would happen for
v5.1.9. Hopefully upstream will decide on a course of action before
that, but if they haven't I'm not against carrying a revert instead of
the RFC patch.
I do I happen to know someone with a Playstation 3 controller so I've asked
them to see if they can reproduce #1713980, as well.
- Jeremy
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] kernel-tools.spec: Adding libbpf package
Hi, On 5/17/19 4:16 AM, Jiri Olsa wrote: On Thu, May 16, 2019 at 04:08:17PM -0700, Laura Abbott wrote: On 5/16/19 2:42 PM, Jiri Olsa wrote: On Wed, Apr 03, 2019 at 06:38:38PM +, Jeremy Cline wrote: Hi Jiri, On 4/2/19 6:35 AM, Jiri Olsa wrote: hi, please consider attached change that adds libbpf sub package to be generated within kernel-tools spec. We need libbpf in a separate package, starting with basic files, some more might come later if there's a need. thanks, jirka --- I've applied this and rebuilt kernel-tools for Rawhide as kernel-tools-5.1.0-0.rc3.git0.2.fc31. hi, it'd be great to have libbpf for Fedora 30 as well, I have scratch build in here: https://koji.fedoraproject.org/koji/taskinfo?taskID=34883714 but I had to add 2 patches on top of v5.0 I assume Fedora 30 will stay on v5.0 .. is there some policy on adding this to Fedora 30? Fedora 30 will get rebased to 5.1 which should be happening sometime next week. We're pretty flexible with what we let into releases so I think it's fine to go in, unless Jeremy sees some issue. that'd be great, thanks Just a heads-up, I've filed the rebase to v5.1.4 for Fedora[0] which contains the libbpf sub-package in kernel-tools. [0] https://bodhi.fedoraproject.org/updates/FEDORA-2019-e96e0ce38b - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] configs: remove CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ
On Wed, May 22, 2019 at 08:42:09PM +0200, Paul Bolle wrote: > Hi Justin, > > Justin Forbes schreef op wo 22-05-2019 om 06:43 [-0500]: > > While it is valid at the moment, it will not be valid once the 5.2 > > secureboot look is redone. > > Thanks for reviewing this patch. > > > That patch was not meant to be dropped. > > How could I have known that? My apologies for not responding earlier. I went on PTO just as you sent the patch and didn't do a great job catching up on email when I came back. Since we're going to bring the sysrq patch back, I think it's best to just leave the setting as-is, but thanks for submitting the fix! - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Rebase plans for kernel 5.1
Hi folks, Another kernel release, another rebase plans email. kernel v5.1 was released yesterday and is now available in the Rawhide repository. We'll be following the usual rebase procedure: after a few stable updates (5.1.2 or 5.1.3) Fedora 30 will be rebased, with Fedora 29 following shortly after that. This will likely occur in early June. Fedora 28 reaches end of life May 28th so it will not be rebased. The kernel-stabilization copr will contain early rebase builds if you are interested in testing early 5.1 kernels. Regards, Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 0/2] Correctly terminate the loop in configs/process_configs.sh
On Mon, May 06, 2019 at 11:01:02AM +0200, Paul Bolle wrote:
> I had a local v5.1 build hang for the second (or third) time because I
> once again forgot to cherry-pick Jeremy's fixup of
> configs/process_configs.sh from commit ece644100170 ("Linux
> v5.0-6399-gf90d64483ebd"). I'm positive Jeremy noticed the need for that
> fixup because a build appeared to hang.
>
> Make sure this doesn't happen again by correctly terminating that loop
> and then die. (Because, obviously, dying is better than hanging!)
>
> Paul Bolle (2):
> configs: properly indent process_configs.sh
> configs: correctly terminate loop
>
> configs/process_configs.sh | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> --
> 2.21.0
>
Applied both patches, thank you!
- Jeremy
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] configs: only visit generic/powerpc once
On 5/1/19 7:29 AM, Paul Bolle wrote: Paul Bolle schreef op di 12-03-2019 om 22:58 [+0100]: The rule that generates kernel-ppc64le-debug.config visits configs/generic/powerpc twice. Stop doing that. Signed-off-by: Paul Bolle --- This can still be seen in current master. I should probably have sent a reminder earlier, but anyhow, could someone please have a look at this trivial cleanup? Thanks for the reminder, I've applied it to master. Regards, Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] kernel-tools.spec: Adding libbpf package
Hi Jiri, On 4/2/19 6:35 AM, Jiri Olsa wrote: hi, please consider attached change that adds libbpf sub package to be generated within kernel-tools spec. We need libbpf in a separate package, starting with basic files, some more might come later if there's a need. thanks, jirka --- I've applied this and rebuilt kernel-tools for Rawhide as kernel-tools-5.1.0-0.rc3.git0.2.fc31. Regards, Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: configs: remove CONFIG_SUN50I_A64_UNSTABLE_TIMER
On 3/19/19 5:38 PM, Paul Bolle wrote:
The patch that added the Kconfig symbol SUN50I_A64_UNSTABLE_TIMER was
dropped in commit 60a8ce36abae7 ("Raspberry Pi DT updates, Update
AllWinner A64 timer errata workaround"). So it's safe to drop it from
the configuration generation system too.
Signed-off-by: Paul Bolle
---
All three patches have been applied, thanks!
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 1/2] Fix typo CROS_EC_DEBUGFS
Hi, On Tue, Mar 12, 2019 at 10:56:56PM +0100, Paul Bolle wrote: > CROS_EC_DEBUGFS should be CONFIG_CROS_EC_DEBUGFS. > > Signed-off-by: Paul Bolle > --- > configs/fedora/generic/x86/x86_64/CONFIG_CROS_EC_DEBUGFS | 2 +- > kernel-x86_64-debug.config | 1 - > kernel-x86_64.config | 1 - > 3 files changed, 1 insertion(+), 3 deletions(-) > > diff --git a/configs/fedora/generic/x86/x86_64/CONFIG_CROS_EC_DEBUGFS > b/configs/fedora/generic/x86/x86_64/CONFIG_CROS_EC_DEBUGFS > index ed6647bbb0c8..06903f17cc05 100644 > --- a/configs/fedora/generic/x86/x86_64/CONFIG_CROS_EC_DEBUGFS > +++ b/configs/fedora/generic/x86/x86_64/CONFIG_CROS_EC_DEBUGFS > @@ -1 +1 @@ > -# CROS_EC_DEBUGFS is not set > +# CONFIG_CROS_EC_DEBUGFS is not set > diff --git a/kernel-x86_64-debug.config b/kernel-x86_64-debug.config > index 060aeec369a9..f7dbcf008410 100644 > --- a/kernel-x86_64-debug.config > +++ b/kernel-x86_64-debug.config > @@ -6652,4 +6652,3 @@ CONFIG_ZSWAP=y > # CONFIG_ZYNQMP_FIRMWARE_DEBUG is not set > # CONFIG_ZYNQMP_PM_DOMAINS is not set > # CONFIG_ZYNQMP_POWER is not set > -# CROS_EC_DEBUGFS is not set > diff --git a/kernel-x86_64.config b/kernel-x86_64.config > index 1cf5d598c616..1f1ca0d53dd9 100644 > --- a/kernel-x86_64.config > +++ b/kernel-x86_64.config > @@ -6631,4 +6631,3 @@ CONFIG_ZSWAP=y > # CONFIG_ZYNQMP_FIRMWARE_DEBUG is not set > # CONFIG_ZYNQMP_PM_DOMAINS is not set > # CONFIG_ZYNQMP_POWER is not set > -# CROS_EC_DEBUGFS is not set > -- > 2.17.2 > This one ended up getting disabled in generic/ so I deleted x86 and arm config. I'm going to blame all these typos on the time change. Thanks for pointing it out! ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] Fix filename typo CONFIG_STACKINIT
Hi,
On Tue, Mar 12, 2019 at 10:53:21PM +0100, Paul Bolle wrote:
> CONFIG_STACKINIT should be CONFIG_TEST_STACKINIT, even though this typo
> has no effect on the build.
>
> Signed-off-by: Paul Bolle
> ---
> .../fedora/generic/{CONFIG_STACKINIT => CONFIG_TEST_STACKINIT}| 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename configs/fedora/generic/{CONFIG_STACKINIT => CONFIG_TEST_STACKINIT}
> (100%)
>
> diff --git a/configs/fedora/generic/CONFIG_STACKINIT
> b/configs/fedora/generic/CONFIG_TEST_STACKINIT
> similarity index 100%
> rename from configs/fedora/generic/CONFIG_STACKINIT
> rename to configs/fedora/generic/CONFIG_TEST_STACKINIT
> --
> 2.17.2
>
Oof. Applied, thanks!
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Request for CONFIG_SPI_SPIDEV in Fedora kernels
Hi, On 3/11/19 12:05 PM, Christoph M. wrote: On Mon, Mar 11, 2019 at 4:51 PM Peter Robinson wrote: On Mon, Mar 11, 2019 at 3:18 PM Justin Forbes wrote: On Mon, Mar 11, 2019 at 8:34 AM Prarit Bhargava wrote: On 3/10/19 5:53 PM, Peter Robinson wrote: On Sun, Mar 10, 2019 at 9:46 PM Christoph M. wrote: On Sun, Mar 10, 2019 at 10:39 PM Peter Robinson < pbrobin...@gmail.com> wrote: Hi Fedora kernel team, I'd like to access SPI devices via the spidev user API ([1]) on my Fedora system. Would it be possible to enable CONFIG_SPI_SPIDEV (module would be fair enough), so that I don't have to build my own kernel? Which architectures or sort of device? I'd like to have that for x86-64 (I want to control an SPI-attached display). Any particular drivers? Or just SPI_SPIDEV FWIW, in RHEL we have ./redhat/configs/debug/aarch64/CONFIG_SPI_DEBUG:CONFIG_SPI_DEBUG=y ./redhat/configs/generic/aarch64/CONFIG_SPI:CONFIG_SPI=y ./redhat/configs/generic/aarch64/CONFIG_SPI_CADENCE:CONFIG_SPI_CADENCE=m ./redhat/configs/generic/aarch64/CONFIG_SPI_MASTER:CONFIG_SPI_MASTER=y ./redhat/configs/generic/aarch64/CONFIG_SPI_PL022:CONFIG_SPI_PL022=m ./redhat/configs/generic/aarch64/CONFIG_SPI_QUP:CONFIG_SPI_QUP=y ./redhat/configs/generic/aarch64/CONFIG_SPI_XLP:CONFIG_SPI_XLP=m ./redhat/configs/generic/x86_64/CONFIG_SPI:CONFIG_SPI=y I don't have a problem with these going in the 5.0 rebase. We already have it all enabled on aarch64, and Arm in general, I actually question how useful the RHEL config is on non aarch64 as it doesn't enable CONFIG_SPI_SPIDEV or CONFIG_SPI_MASTER which I think are generally needed for it to be useful, but maybe CONFIG_SPI enables them, I've not looked. CONFIG_SPI is required for any CONFIG_SPI*. CONFIG_SPI_MASTER is required for CONFIG_SPI_SPIDEV. https://elixir.bootlin.com/linux/latest/source/drivers/spi/Kconfig#L25 I've turned on SPI_SPIDEV on x86 and it's in today's Rawhide build. I've also pushed it to the f30 branch so it should be in the 5.0.2 build. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] Remove a patch that still touches userspace tools
On 3/8/19 3:57 PM, Paul Bolle wrote: The userspace tools were split out into kernel-tools in 2017. Remove a patch that still touches them. Signed-off-by: Paul Bolle Applied, thanks! ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
