[PATCH] drm/i915/tgl/psr: Disable PSR on Tigerlake for now
Currently PSR2 appears to be broken on TGL which causes some pretty nasty
refresh issues. Intel doesn't have a fix for this quite yet, and this
definitely affects a couple of OEM machines shipping with Fedora.
We don't have a better workaround for the time being, so just disable PSR2
outright for Tigerlake by default until this gets fixed.
Signed-off-by: Lyude Paul
Cc: Jared Dominguez
Cc: Mark Pearson
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3134
---
drivers/gpu/drm/i915/display/intel_psr.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 850cb7f5b332..48ea3a42feb2 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1817,9 +1817,14 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
*/
dev_priv->hsw_psr_mmio_adjust = _SRD_CTL_EDP -
_HSW_EDP_PSR_BASE;
- if (dev_priv->params.enable_psr == -1)
- if (INTEL_GEN(dev_priv) < 9 || !dev_priv->vbt.psr.enable)
+ if (dev_priv->params.enable_psr == -1) {
+ if (INTEL_GEN(dev_priv) < 9 || !dev_priv->vbt.psr.enable) {
dev_priv->params.enable_psr = 0;
+ } else if (INTEL_GEN(dev_priv) == 12) {
+ /* See
https://gitlab.freedesktop.org/drm/intel/-/issues/3134 */
+ dev_priv->params.enable_psr = 0;
+ }
+ }
/* Set link_standby x link_off defaults */
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
--
2.30.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
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
Re: Is it acceptable to package non-bootable kernels?
Justin, On Tue, Mar 23, 2021 at 10:30 PM Justin Forbes wrote: > > On Mon, Mar 22, 2021 at 4:23 AM Sergio Lopez wrote: > > > > Hi, > > > > Now that libkrun, libkrunfw and krunvm have landed in openSUSE > > Tumbleweed [1], I think it's a good time to reopen this discussion. I > > also had plenty of time to think about it, and my thoughts are now > > clearer, so please let me explain again why bundling a custom kernel > > with patches is a critical aspect of the libkrun project, and why this > > doesn't pose a risk for neither the Fedora Kernel Team, nor Fedora as > > a whole. > > > > I like to define libkrun as "a dynamic library that enables other > > programs to easily gain Virtualization-based isolation capabilities, > > with the minimum possible footprint". While it does integrate the > > functionality of a VMM (Virtual Machine Monitor), in many aspects is > > closer to gVisor [2] than to QEMU [3], with the difference that gVisor > > uses a microkernel built for that specific purpose, while libkrun > > relies on a custom Linux kernel bundled in libkrunfw. > > > > It's in the very nature of the project the need to explore building > > new bridges that allow the isolated workload running in the VM to > > communicate with the Host, in ways that are more appropriate to > > fulfill the needs of use cases such as "Lightweight VMs", > > "Virtualization-isolated Containers" or "Trusted Execution > > Environments (TEEs)". And this, out of necessity, implies extending > > both libkrun and the kernel bundled with it. > > > > Now, I do understand why the actual kernel shipped with Fedora, the > > one that will be used by booting thousands of machines and will be > > running in privileged mode, needs to be held to sky-high standards, > > which may also include the restriction to not include additional > > patches, unless it's strongly justified. But, I also think that the > > kernel bundled in libkrunfw shouldn't be held by such standards. > > > > The kernel bundled in libkrunfw can and only will be used by libkrun > > to bring up the Virtualized environment where the isolated workload > > will run. It will only be used in a Virtualization-isolated context, > > usually by unprivileged users, and in most cases in a > > pre-containerized environment. I argue, and this is a hill I'm willing > > to die on, that a bug in either the kernel bundled in libkrunfw or in > > libkrun itself, can't cause any more damage than any other userspace > > application shipped in Fedora. In fact, the risk is usually lower, > > given the context described before. > > > > Having librunfw following the same high standards as the main kernel, > > we could end up going against our ability to provide new features to > > the users in a timely manner and gather a much needed feedback that's > > critical to the success of this project. In practice, this inhibits > > the possibility of using Fedora as the main upstream distribution for > > libkrun and the projects depending on it. And this would be very > > unfortunate, given the roots of libkrun > > > > So, for the reasons stated above, I'd would like to reopen this > > question to see if together we can find a compromise that would work > > for all of us. > > > > The kernel in this case is a part of the libkrunfw package? Sergio will correct me if I'm mistaken, but libkrunfw actually *is* the kernel bundled in a dynamic library. So, yes, the kernel, in this case, will be shipped as libkrunfw and there's absolutely no way it will be mistaken as the "Fedora Kernel". > I don't > have a problem with this particular use case, it is not a "kernel" > package, and would not be mistaken as the proper kernel in any sort of > a real context. Perfect! With this in mind, I guess we can simply go ahead and file the bug for adding the package to Fedora. Sergio, I could happily review that. :-) > On a philosophical note, I would like to see some > effort of getting the patches required upstream in some manner, as any > project relying on external patches long term is just asking for a lot > of unnecessary pain. Even with the patches upstreamed though, a > separate build is still required, and I believe this solution is > acceptable. Justin, I can say, without any doubt, that we're on the same page here. There's absolutely zero intent to keep patches downstream, which would only generate us a huge maintenance burden. However, we may have to, in some cases, at least for some time. Best Regards, -- Fabiano Fidêncio ___ 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:
Re: Is it acceptable to package non-bootable kernels?
On Mon, Mar 22, 2021 at 4:23 AM Sergio Lopez wrote: > > Hi, > > Now that libkrun, libkrunfw and krunvm have landed in openSUSE > Tumbleweed [1], I think it's a good time to reopen this discussion. I > also had plenty of time to think about it, and my thoughts are now > clearer, so please let me explain again why bundling a custom kernel > with patches is a critical aspect of the libkrun project, and why this > doesn't pose a risk for neither the Fedora Kernel Team, nor Fedora as > a whole. > > I like to define libkrun as "a dynamic library that enables other > programs to easily gain Virtualization-based isolation capabilities, > with the minimum possible footprint". While it does integrate the > functionality of a VMM (Virtual Machine Monitor), in many aspects is > closer to gVisor [2] than to QEMU [3], with the difference that gVisor > uses a microkernel built for that specific purpose, while libkrun > relies on a custom Linux kernel bundled in libkrunfw. > > It's in the very nature of the project the need to explore building > new bridges that allow the isolated workload running in the VM to > communicate with the Host, in ways that are more appropriate to > fulfill the needs of use cases such as "Lightweight VMs", > "Virtualization-isolated Containers" or "Trusted Execution > Environments (TEEs)". And this, out of necessity, implies extending > both libkrun and the kernel bundled with it. > > Now, I do understand why the actual kernel shipped with Fedora, the > one that will be used by booting thousands of machines and will be > running in privileged mode, needs to be held to sky-high standards, > which may also include the restriction to not include additional > patches, unless it's strongly justified. But, I also think that the > kernel bundled in libkrunfw shouldn't be held by such standards. > > The kernel bundled in libkrunfw can and only will be used by libkrun > to bring up the Virtualized environment where the isolated workload > will run. It will only be used in a Virtualization-isolated context, > usually by unprivileged users, and in most cases in a > pre-containerized environment. I argue, and this is a hill I'm willing > to die on, that a bug in either the kernel bundled in libkrunfw or in > libkrun itself, can't cause any more damage than any other userspace > application shipped in Fedora. In fact, the risk is usually lower, > given the context described before. > > Having librunfw following the same high standards as the main kernel, > we could end up going against our ability to provide new features to > the users in a timely manner and gather a much needed feedback that's > critical to the success of this project. In practice, this inhibits > the possibility of using Fedora as the main upstream distribution for > libkrun and the projects depending on it. And this would be very > unfortunate, given the roots of libkrun > > So, for the reasons stated above, I'd would like to reopen this > question to see if together we can find a compromise that would work > for all of us. > The kernel in this case is a part of the libkrunfw package? I don't have a problem with this particular use case, it is not a "kernel" package, and would not be mistaken as the proper kernel in any sort of a real context. On a philosophical note, I would like to see some effort of getting the patches required upstream in some manner, as any project relying on external patches long term is just asking for a lot of unnecessary pain. Even with the patches upstreamed though, a separate build is still required, and I believe this solution is acceptable. Justin ___ 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
Re: Is it acceptable to package non-bootable kernels?
Matthew, On Tue, Mar 23, 2021 at 8:31 PM Matthew Miller wrote: > > On Mon, Mar 22, 2021 at 10:23:24AM +0100, Sergio Lopez wrote: > > So, for the reasons stated above, I'd would like to reopen this > > question to see if together we can find a compromise that would work > > for all of us. > > This all sounds good to me. What are we blocked on? Right now we're blocked on having an agreement with the kernel team in order to proceed with a kernel that is different from the one shipped and used by Fedora. Once we have this approval, I guess the next step would be updating the current documents on what can (or cannot) be shipped, and what's the approach to follow in such cases, and then, finally, we can proceed with packaging libkrunfw. AFAIU, the approval must come from the Fedora kernel team. If this ML is not exactly the best way, could someone redirect us to the best way to approach the team and recommend the next steps from here? One note, Dan Walsh's email seems to be blocked waiting for the moderator to approve it, as it didn't show up here. In any case, Dan mentioned, and I'm quoting here as is: """ I would like to also recommend that this be reconsidered. We would like to make libkrun a first class citizen as a crun based OCI Runtime. We see benefits for it in both on Linux (Fedora) platforms as it provides a easy to use KVM Container, which works easier with the host then Kata. Secondarily with MAC systems, since it provides a light weight way of running containers on a MAC. In my option, having Fedora's name associated with this innovative technology would be beneficial to Fedora project. """ Best Regards, -- Fabiano Fidêncio ___ 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
Re: Is it acceptable to package non-bootable kernels?
On 3/22/21 05:23, Sergio Lopez wrote: Hi, Now that libkrun, libkrunfw and krunvm have landed in openSUSE Tumbleweed [1], I think it's a good time to reopen this discussion. I also had plenty of time to think about it, and my thoughts are now clearer, so please let me explain again why bundling a custom kernel with patches is a critical aspect of the libkrun project, and why this doesn't pose a risk for neither the Fedora Kernel Team, nor Fedora as a whole. I like to define libkrun as "a dynamic library that enables other programs to easily gain Virtualization-based isolation capabilities, with the minimum possible footprint". While it does integrate the functionality of a VMM (Virtual Machine Monitor), in many aspects is closer to gVisor [2] than to QEMU [3], with the difference that gVisor uses a microkernel built for that specific purpose, while libkrun relies on a custom Linux kernel bundled in libkrunfw. It's in the very nature of the project the need to explore building new bridges that allow the isolated workload running in the VM to communicate with the Host, in ways that are more appropriate to fulfill the needs of use cases such as "Lightweight VMs", "Virtualization-isolated Containers" or "Trusted Execution Environments (TEEs)". And this, out of necessity, implies extending both libkrun and the kernel bundled with it. Now, I do understand why the actual kernel shipped with Fedora, the one that will be used by booting thousands of machines and will be running in privileged mode, needs to be held to sky-high standards, which may also include the restriction to not include additional patches, unless it's strongly justified. But, I also think that the kernel bundled in libkrunfw shouldn't be held by such standards. The kernel bundled in libkrunfw can and only will be used by libkrun to bring up the Virtualized environment where the isolated workload will run. It will only be used in a Virtualization-isolated context, usually by unprivileged users, and in most cases in a pre-containerized environment. I argue, and this is a hill I'm willing to die on, that a bug in either the kernel bundled in libkrunfw or in libkrun itself, can't cause any more damage than any other userspace application shipped in Fedora. In fact, the risk is usually lower, given the context described before. Having librunfw following the same high standards as the main kernel, we could end up going against our ability to provide new features to the users in a timely manner and gather a much needed feedback that's critical to the success of this project. In practice, this inhibits the possibility of using Fedora as the main upstream distribution for libkrun and the projects depending on it. And this would be very unfortunate, given the roots of libkrun So, for the reasons stated above, I'd would like to reopen this question to see if together we can find a compromise that would work for all of us. Thanks, Sergio. [1] https://build.opensuse.org/package/show/openSUSE:Factory/libkrun [2] https://gvisor.dev/ [3] https://www.qemu.org/ I would like to also recommend that this be reconsidered. We would like to make libkrun a first class citizen as a crun based OCI Runtime. We see benefits for it in both on Linux (Fedora) platforms as it provides a easy to use KVM Container, which works easier with the host then Kata. Secondarily with MAC systems, since it provides a light weight way of running containers on a MAC. In my option, having Fedora's name associated with this innovative technology would be beneficial to Fedora project. ___ 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
Re: [OS-BUILD PATCH] [redhat] New configs in drivers/pci
On Mon, 01 Mar 2021 13:40:29 - "CKI Gitlab (via Email Bridge)" wrote: > From: Fedora Kernel Team > > [redhat] New configs in drivers/pci > > 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_PCIE_MICROCHIP_HOST: > > Say Y here if you want kernel to support the Microchip AXI PCIe > Host Bridge driver. > > Symbol: PCIE_MICROCHIP_HOST [=n] > Type : bool > Defined at drivers/pci/controller/Kconfig:278 >Prompt: Microchip AXI PCIe host bridge support >Depends on: PCI [=y] && PCI_MSI [=y] && OF [=y] >Location: > -> Device Drivers >-> PCI support (PCI [=y]) > -> PCI controller drivers > Selects: PCI_MSI_IRQ_DOMAIN [=y] && GENERIC_MSI_IRQ_DOMAIN [=y] && > PCI_HOST_COMMON [=n] > > --- > > Cc: Myron Stowe > Cc: Prarit Bhargava > Signed-off-by: Fedora Kernel Team > > diff a/redhat/configs/common/generic/CONFIG_PCIE_MICROCHIP_HOST > b/redhat/configs/common/generic/CONFIG_PCIE_MICROCHIP_HOST --- > /dev/null +++ > b/redhat/configs/common/generic/CONFIG_PCIE_MICROCHIP_HOST @@ -0,0 +1 > @@ +# CONFIG_PCIE_MICROCHIP_HOST is not set > diff > a/redhat/configs/pending-common/generic/CONFIG_PCIE_MICROCHIP_HOST > b/redhat/configs/pending-common/generic/CONFIG_PCIE_MICROCHIP_HOST > --- > a/redhat/configs/pending-common/generic/CONFIG_PCIE_MICROCHIP_HOST > +++ /dev/null @@ -1,19 +0,0 @@ -# CONFIG_PCIE_MICROCHIP_HOST: -# > -# Say Y here if you want kernel to support the Microchip AXI PCIe > -# Host Bridge driver. > -# > -# Symbol: PCIE_MICROCHIP_HOST [=n] > -# Type : bool > -# Defined at drivers/pci/controller/Kconfig:278 > -# Prompt: Microchip AXI PCIe host bridge support > -# Depends on: PCI [=y] && PCI_MSI [=y] && OF [=y] > -# Location: > -# -> Device Drivers > -# -> PCI support (PCI [=y]) > -# -> PCI controller drivers > -# Selects: PCI_MSI_IRQ_DOMAIN [=y] && GENERIC_MSI_IRQ_DOMAIN [=y] && > PCI_HOST_COMMON [=n] -# > -# > -# > -# CONFIG_PCIE_MICROCHIP_HOST is not set > > -- > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/932 > Acked-by: Myron Stowe ___ 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
Re: Is it acceptable to package non-bootable kernels?
Hi, Now that libkrun, libkrunfw and krunvm have landed in openSUSE Tumbleweed [1], I think it's a good time to reopen this discussion. I also had plenty of time to think about it, and my thoughts are now clearer, so please let me explain again why bundling a custom kernel with patches is a critical aspect of the libkrun project, and why this doesn't pose a risk for neither the Fedora Kernel Team, nor Fedora as a whole. I like to define libkrun as "a dynamic library that enables other programs to easily gain Virtualization-based isolation capabilities, with the minimum possible footprint". While it does integrate the functionality of a VMM (Virtual Machine Monitor), in many aspects is closer to gVisor [2] than to QEMU [3], with the difference that gVisor uses a microkernel built for that specific purpose, while libkrun relies on a custom Linux kernel bundled in libkrunfw. It's in the very nature of the project the need to explore building new bridges that allow the isolated workload running in the VM to communicate with the Host, in ways that are more appropriate to fulfill the needs of use cases such as "Lightweight VMs", "Virtualization-isolated Containers" or "Trusted Execution Environments (TEEs)". And this, out of necessity, implies extending both libkrun and the kernel bundled with it. Now, I do understand why the actual kernel shipped with Fedora, the one that will be used by booting thousands of machines and will be running in privileged mode, needs to be held to sky-high standards, which may also include the restriction to not include additional patches, unless it's strongly justified. But, I also think that the kernel bundled in libkrunfw shouldn't be held by such standards. The kernel bundled in libkrunfw can and only will be used by libkrun to bring up the Virtualized environment where the isolated workload will run. It will only be used in a Virtualization-isolated context, usually by unprivileged users, and in most cases in a pre-containerized environment. I argue, and this is a hill I'm willing to die on, that a bug in either the kernel bundled in libkrunfw or in libkrun itself, can't cause any more damage than any other userspace application shipped in Fedora. In fact, the risk is usually lower, given the context described before. Having librunfw following the same high standards as the main kernel, we could end up going against our ability to provide new features to the users in a timely manner and gather a much needed feedback that's critical to the success of this project. In practice, this inhibits the possibility of using Fedora as the main upstream distribution for libkrun and the projects depending on it. And this would be very unfortunate, given the roots of libkrun So, for the reasons stated above, I'd would like to reopen this question to see if together we can find a compromise that would work for all of us. Thanks, Sergio. [1] https://build.opensuse.org/package/show/openSUSE:Factory/libkrun [2] https://gvisor.dev/ [3] https://www.qemu.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Building custom kernels
Am 01.03.21 um 22:37 schrieb Justin Forbes: On Sun, Feb 28, 2021 at 12:00 PM Julian Sikorski wrote: W dniu 27.02.2021 o 20:59, Julian Sikorski pisze: Hi, I am trying to test some Renoir s2idle patches [1]. It appears that Fedora kernel source is now maintained on gitlab as kernel-ark [2]. What I tried is adding the patches to the fedora-5.11 branch and running make dist-srpm, but it failed due to config mismatch on CONFIG_INIT_STACK_NONE: Processing /home/julas/cvs/fedora/kernel-ark/redhat/configs/kernel-aarch64-fedora.config ... Error: Mismatches found in configuration files Found CONFIG_INIT_STACK_NONE=y after generation, had CONFIG_INIT_STACK_NONE=is not set in Source tree make[1]: *** [Makefile:145: dist-configs-check] Błąd 1 Is this expected? Is there a better way of testing patches on Fedora kernels? Thanks for the help in advance. Best regards, Julian [1] https://gitlab.freedesktop.org/drm/amd/-/issues/1230 [2] https://gitlab.com/cki-project/kernel-ark Hi, the same keeps happening if I try to merge os-build into agdf5 tree or even if I try to make srpm in the ark-latest branch. Is this normal? I am guessing you are currently on F32? There are unfortunately some config options which are gcc version dependent. I know it has been complained about upstream, but they exist. Justin I am on F33 x86_64. In case F33 is affected too, is there a workaround beyond building the kernel from a rawhide VM? Best regards, Julian ___ 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
Re: Building custom kernels
W dniu 27.02.2021 o 20:59, Julian Sikorski pisze: Hi, I am trying to test some Renoir s2idle patches [1]. It appears that Fedora kernel source is now maintained on gitlab as kernel-ark [2]. What I tried is adding the patches to the fedora-5.11 branch and running make dist-srpm, but it failed due to config mismatch on CONFIG_INIT_STACK_NONE: Processing /home/julas/cvs/fedora/kernel-ark/redhat/configs/kernel-aarch64-fedora.config ... Error: Mismatches found in configuration files Found CONFIG_INIT_STACK_NONE=y after generation, had CONFIG_INIT_STACK_NONE=is not set in Source tree make[1]: *** [Makefile:145: dist-configs-check] Błąd 1 Is this expected? Is there a better way of testing patches on Fedora kernels? Thanks for the help in advance. Best regards, Julian [1] https://gitlab.freedesktop.org/drm/amd/-/issues/1230 [2] https://gitlab.com/cki-project/kernel-ark Hi, the same keeps happening if I try to merge os-build into agdf5 tree or even if I try to make srpm in the ark-latest branch. Is this normal? Best regards, Julian ___ 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
Re: [OS-BUILD PATCHv3 0/2] [redhat] New configs in net/netfilter
On Thu, 18 Feb 2021 10:24:42 - "CKI Gitlab (via Email Bridge)" wrote: > From: CKI Gitlab on gitlab.com > Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/812 > > 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_NFT_REJECT_NETDEV: > > This option enables the REJECT support from the netdev table. > The return packet generation will be delegated to the IPv4 > or IPv6 ICMP or TCP RST implementation depending on the > protocol of the packet. > > Symbol: NFT_REJECT_NETDEV [=n] > Type : tristate > Defined at net/netfilter/Kconfig:685 >Prompt: Netfilter nf_tables netdev REJECT support >Depends on: NET [=y] && INET [=y] && NETFILTER [=y] && NF_TABLES [=m] > && NF_TABLES_NETDEV [=y] && NFT_REJECT_IPV4 [=m] && NFT_REJECT_IPV6 [=m] >Location: > -> Networking support (NET [=y]) >-> Networking options > -> Network packet filtering framework (Netfilter) (NETFILTER > [=y]) >-> Core Netfilter Configuration > -> Netfilter nf_tables support (NF_TABLES [=m]) > > --- > > Cc: Florian Westphal > Cc: Jiri Benc > Cc: Marcelo Leitner > Cc: Davide Caratti > Cc: Eric Garver > Cc: Flavio Leitner > Cc: Guillaume Nault > Cc: Hangbin Liu > Cc: Ivan Vecera > Cc: Jarod Wilson > Cc: Lorenzo Bianconi > Cc: Paolo Abeni > Cc: Phil Sutter > Cc: Sabrina Dubroca > Cc: Stefano Brivio > Cc: Xin Long > Signed-off-by: Fedora Kernel Team > Acked-by: Ivan Vecera ___ 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
Re: Kernel version plans for Fedora 34 ?
On Fri, 2021-02-12 at 14:07 +0100, Bastien Nocera wrote: > On Thu, 2021-02-11 at 17:23 -0600, Justin Forbes wrote: > > On Thu, Feb 11, 2021 at 1:01 PM Bastien Nocera > > wrote: > > > > > > On Thu, 2021-02-11 at 19:32 +0100, Hans de Goede wrote: > > > > > > > So where do I submit these once backported ? Do I just add > > > > them > > > > to > > > > dist-git > > > > as before ? AFAIK 5.11 will be the first kernel-ark based > > > > Fedora > > > > kernel > > > > (at least 5.10 dist-git does not look ark based), right ? > > > > > > I recently wanted to do that for a Bluetooth patch, and this is > > > how > > > I > > > went about it, along with discussions that happened on the list: > > > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/872 > > > > > > I don't know whether I would have needed to proceed to get this > > > particular patch into stable releases, like Fedora 33 though. > > > > > > > The Fedora stable branches are a bit different, in that they do not > > copy over to ELN, so it is a much less formal process. Basically > > either I take it or I don't. And that is typically determined by a) > > What is the upstream status? b) How invasive is the backport? c) > > What > > is it trying to solve? > > Coming back to the merge request I filed, I think that all 3 of those > questions are answered. > > Do I need to do anything else? A separate merge request? Justin, can you please explain what's needed to land upstream patches into stable versions of Fedora, with the above patch as an example? The merge request I filed against what will be the rawhide kernel has all the 3 bits of information you requested. Is something missing? How do we need to contribute the upstream changes to make it as easy as possible for you, so those patches get into stable kernels quickly? Cheers ___ 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
Re: [OS-BUILD PATCH] [redhat] New configs in sound/soc
From: Jaroslav Kysela on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/729#note_536082044 Acked-by: Jaroslav Kysela ___ 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
Re: Is it acceptable to package non-bootable kernels?
On Mon, Mar 22, 2021 at 10:23:24AM +0100, Sergio Lopez wrote: > So, for the reasons stated above, I'd would like to reopen this > question to see if together we can find a compromise that would work > for all of us. This all sounds good to me. What are we blocked on? -- Matthew Miller Fedora Project Leader ___ 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
Re: [OS-BUILD PATCH] [redhat] New configs in drivers/tty
From: John Linville on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/809#note_536069681 I'm not seeing an "approve" button...does this work? Acked-by: John W. Linville ___ 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
Re: [OS-BUILD PATCH] [redhat] New configs in fs/Kconfig
From: Eric Sandeen on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/579#note_536054601 Honestly, I'd suggest that we turn this into a "=Y" and enable 64-bit inodes by default. It can be overridden by mounting tmpfs with -o inode32 for any 32-bit userspace that needs it, and the failure (EOVERFLOW) should be obvious. XFS already defaults to 64-bit inodes, with a similar mount-time override, so at least some of our current users are aware of this type of concern. ___ 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
Re: [OS-BUILD PATCH] [redhat] New configs in drivers/watchdog
From: Mark Salter on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/418#note_535976923 So we don't need this for ARK, but Fedora does enable it as a module. ___ 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
Re: [OS-BUILD PATCHv2] New configs in drivers/net/phy
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/410#note_535946736 @poros2 - i add you as Developer, the button should be there now. Sorry about that. ___ 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
Re: [OS-BUILD PATCHv2] [redhat] Enable PERCPU_STATS and CRYPTO_DEV_CCP_DEBUGFS in the debug flavor
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/954#note_535944229 @raquini - add you as Developer so you can use 'lab' now. ___ 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
Re: [OS-BUILD PATCHv3 0/0] [redhat] New configs in drivers/md
From: Nigel Croxon on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/834#note_535880503 Acked-by: Nigel Croxon ___ 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
Re: [OS-BUILD PATCH] [redhat] New configs in mm/Kconfig
From: Rafael Aquini on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/810#note_535866444 Acked-by: Rafael Aquini ___ 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
Re: [OS-BUILD PATCHv2] New configs in drivers/net/phy
From: Petr Oros on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/410#note_535856035 The button is not here. Acked-by: Petr Oros ___ 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
Re: [OS-BUILD PATCHv2] [redhat] Enable PERCPU_STATS and CRYPTO_DEV_CCP_DEBUGFS in the debug flavor
From: Ondrej Mosnáček on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/954#note_535845325 @dzickusrh Thanks! It seems it was recorded correctly anyway, but at least I can now ack with just a click of a button :) ___ 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
Re: [OS-BUILD PATCH 0/0] all/common/ark: minor cleanups and fix ups
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/956#note_535844591 @Lyude - added you as a Developer to this project. This should give you the approve button. Sorry about that. ___ 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
Re: [OS-BUILD PATCHv2] [redhat] Enable PERCPU_STATS and CRYPTO_DEV_CCP_DEBUGFS in the debug flavor
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/954#note_535840755 @NefigTut - hopefully by adding @omos to the Developer list, resolves the permission problem and his ack is recorded. ___ 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
Re: [OS-BUILD PATCHv2] New configs in drivers/input
From: Aristeu Rozanski on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/453#note_535838384 Rescind-Nacked-by: Aristeu Rozanski ___ 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
Re: [OS-BUILD PATCH] [redhat] Unify crypto CHACHA20 and POLY1305 configs
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/951#note_535836621 @omos - you don't have access to the approve button because you are not listed as a Developer for the project. I have been manually adding people. I have to resolve this. I will add you manually for now. ___ 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
Re: [OS-BUILD PATCHv2] New configs in mm/Kconfig
From: Rafael Aquini on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/406#note_535816171 Acked-by: Rafael Aquini ___ 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
Re: [OS-BUILD PATCHv2] New configs in drivers/input
From: Aristeu Rozanski on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/453#note_535798131 rescind-nack ___ 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
Re: [OS-BUILD PATCHv2] [redhat] Enable PERCPU_STATS and CRYPTO_DEV_CCP_DEBUGFS in the debug flavor
From: Rafael Aquini on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/954#note_535789304 @dzickusrh, I guess the problem is that we cannot review/approve kernel- ark MRs with lab. ___ 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
Re: [OS-BUILD PATCHv2] New configs in drivers/net/phy
From: Patrick Talbert on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/410#note_535782600 Hey Petr, Can you click the Approve button in the UI or leave a `Acked-by: NAME ` comment? Thank you, Patrick ___ 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
Re: [OS-BUILD PATCH] New configs in arch/powerpc
From: Steve Best on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/249#note_535781733 Acked-by: Steve Best ___ 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
Re: [OS-BUILD PATCHv2] [redhat] Enable PERCPU_STATS and CRYPTO_DEV_CCP_DEBUGFS in the debug flavor
From: Rafael Aquini on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/954#note_535781061 Acked-by: Rafael Aquini ___ 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
Re: [OS-BUILD PATCH] New configs in arch/powerpc
From: Steve Best on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/278#note_535772792 Acked-by: Steve Best ___ 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
Re: [OS-BUILD PATCHv2] New configs in drivers/bus
From: Mark Salter on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/421#note_535767324 Myron is correct. This should go in redhat/configs/common/generic/arm ___ 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
Re: [OS-BUILD PATCH] [redhat] New configs in fs/xfs
From: Patrick Talbert on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/738#note_535765983 You can respond to the email with the standard `Acked-by: NAME ` and that should be good enough. Or if you have 'lab' set up and want to approve the MR then: $ lab mr approve 738 ___ 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
Re: [OS-BUILD PATCHv2] New configs in drivers/input
From: Aristeu Rozanski on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/453#note_535717366 I'm not sure how this should be done without a mail bridge, but: Nacked-by: Aristeu Rozanski See the comment I made 5 months ago. ___ 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
Re: [OS-BUILD PATCH] New configs in arch/powerpc
From: Daniel Horak on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/278#note_535706036 LGTM Acked-by: Dan Horák ___ 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
Re: [OS-BUILD PATCH 0/0] all/common/ark: minor cleanups and fix ups
From: Prarit Bhargava on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/956#note_535704414 >(^ will that work? I don't see any approve button on this MR for some reason…) @dzickusrh ___ 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
Re: [OS-BUILD PATCHv2] [redhat] Enable PERCPU_STATS and CRYPTO_DEV_CCP_DEBUGFS in the debug flavor
From: Vladis Dronov on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/954#note_535541985 Thanks, @omos, Unfortunately, it looks like there is a permission issue in this ARK repo. ___ 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
Re: [OS-BUILD PATCH] [redhat] Unify crypto CHACHA20 and POLY1305 configs
From: Vladis Dronov on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/951#note_535540959 interesting. my another teammate also do not have an approve button, while he can approve in the redhat/rhel/src/kernel/rhel-8 repo. this means, this most likely is a permission issue. @dzickusrh could you please advise on getting a permission to approve in this repo? ___ 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
Re: [OS-BUILD PATCH] [redhat] Unify crypto CHACHA20 and POLY1305 configs
From: Ondrej Mosnáček on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/951#note_535454221 IIRC, the effect of a comment/email ack is not visible until there are at least two... So the bot may or may not parse my ack, but we won't know until someone else adds their ack. That's why I'm asking about the approve button support, because that at least visibly records the individual approvals in the MR's metadata... ___ 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
Re: [OS-BUILD PATCHv2] [redhat] Enable PERCPU_STATS and CRYPTO_DEV_CCP_DEBUGFS in the debug flavor
From: Vladis Dronov on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/954#note_535443648 Thanks, @omos, Unfortunately, it looks like just commenting with "Acked- by:" does not work, this MR still has "0 Reviewers". Obvious, but were you logged in 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] [redhat] Unify crypto CHACHA20 and POLY1305 configs
From: Vladis Dronov on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/951#note_535442678 Don, Ondrej, thanks for looking into this. Unfortunately, it looks like just commenting with "Acked-by:" does not work, this MR still has "0 Reviewers". Obvious, but were you logged in 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2] New configs in drivers/net/phy
From: Petr Oros on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/410#note_535413410 LGTM ___ 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
Re: [OS-BUILD PATCHv4] redhat: add initial support for centos stream dist-git sync on Makefiles
From: Jan Stancek on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/977#note_535389790 Fine by me. Acked-by: Jan Stancek ___ 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
