Re: Small rant: installer environment size

[Peter Robinson]

On Thu, Dec 8, 2022 at 4:56 PM Adam Williamson
 wrote:
>
> On Thu, 2022-12-08 at 12:58 +, Peter Robinson wrote:
> >
> > I've done a few passes, dropping a bunch of older firmware upstream
> > that are no longer supported in any stable kernel release, also a
> > bunch of de-dupe and linking of files rather than shipping of multiple
> > copies of the same firmware. It's improved things a bit, unfortunately
> > a lot of the dead firmware was tiny compared to say average modern
> > devices like GPUs or WiFI.
> >
> > The problem with a lot of the firmware, and with the new nvidia "open
> > driver" which shoves a lot of stuff into firmware in order to have an
> > upstreamable driver apparently the firmwares there are going to be
> > 30+Mb each, is that they're needed to bring up graphics/network etc to
> > even just install so I don't know how we can get around this and still
> > have a device work enough to be able to install the needed firmware
> > across the network.
> >
> > Ideas on how to solve that problem welcome.
>
> Sorry if this is way off, but - do we need the GPU firmwares to run a
> graphical install on the fallback path, just using the framebuffer set
> up by the firmware? How crazy would it be to just do that - ship the
> installer env with no GPU firmware?

That has crossed my mind, and with simpledrm that may be more straight
forward now, but TBH it's not something I am skilled enough to deal
with, nor have the resources to test, or actually care enough about,
but the big GPU firmwares are now all split out so that should be much
more straightforward for someone with the resources to investigate.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Peter Robinson]

On Thu, Dec 8, 2022 at 12:42 AM Adam Williamson
 wrote:
>
> Hi folks! Today I woke up and found
> https://bugzilla.redhat.com/show_bug.cgi?id=2151495 , which diverted me
> down a bit of an "installer environment size" rabbit hole.
>
> As of today, with that new dep in webkitgtk, Rawhide's network install
> images are 703M in size. Here's a potted history of network install
> image sizes:
>
> Fedora Core 8: 103.2M (boot.iso 9.2M + stage2.img 94M)
> Fedora 13: 208M
> Fedora 17: 162M (last "old UI")
> Fedora 18: 294M (first "new UI")
> Fedora 23: 415M
> Fedora 28: 583M
> Fedora 33: 686M
> Fedora 37: 665M
> Fedora Rawhide: 703M
>
> The installer does not really do much more in Rawhide than it did in
> FC8. Even after the UI rewrite in F18, we were only at 294M. Now the
> image is well over 2x as big and does...basically the same.
>
> Why does this matter? Well, the images being large is moderately
> annoying in itself just in terms of transfer times and so on. But more
> importantly, AIUI at least, the entire installer environment is loaded
> into RAM at startup - it kinda has to be, we don't have anywhere else
> to put it. The bigger it is, the more RAM you need to install Fedora.
> The size of the installer environment (for which the size of the
> network install image is more or less a perfect proxy) is one of the
> two key factors in this, the other being how much RAM DNF uses during
> package install.
>
> So, I did a bit of poking about into *what* is taking up all that
> space. There's a variety of answers, but there's two major culprits:
>
> 1. firmware
> 2. yelp (which pulls in webkitgtk and its deps)
>
> I've been using du and baobab (the GNOME visual disk usage analyzer,
> which is great) to examine the filesystems, but I ran a couple of test
> builds to confirm these suspects, especially after the impact of
> compression (it's hard to check the *compressed* size of things in the
> installer environment directly).
>
> I did a scratch build of lorax which does not pull in firmware
> packages, and had openQA build a netinst using that lorax. It came out
> at 489M - 214M smaller than current netinsts, a size we last managed in
> Fedora 26. I did a scratch build of anaconda with its requirement of
> yelp dropped (which would break help pages), and built a netinst with
> that; it came out at 662M - 41M smaller than current images. I haven't
> run a combined test yet, but it ought to come out around 448M, around
> the size of Fedora 24.
>
> Even then we'd still be about 50% larger than the Fedora 18 image, for
> not really any added functionality.
>
> I've moaned about the sheer amount and size of firmware blobs in other
> forums before, but 214M compressed is *really* obnoxious. We must be
> able to do something to clean this up (further than it's already
> cleaned up - this is *after* we dropped low-hanging fruit like
> enterprise switch 'firmwares' and garbage like that; most of the
> remaining size seems to be huge amounts of probably-very-similar
> firmware files for AMD graphics adapters and Intel wireless adapters).
> I know some folks were trying to work on this (there was talk that we
> could drop quite a lot of files that would only be loaded by older
> kernels no longer in Fedora); any news on how far along that effort is?

I've done a few passes, dropping a bunch of older firmware upstream
that are no longer supported in any stable kernel release, also a
bunch of de-dupe and linking of files rather than shipping of multiple
copies of the same firmware. It's improved things a bit, unfortunately
a lot of the dead firmware was tiny compared to say average modern
devices like GPUs or WiFI.

The problem with a lot of the firmware, and with the new nvidia "open
driver" which shoves a lot of stuff into firmware in order to have an
upstreamable driver apparently the firmwares there are going to be
30+Mb each, is that they're needed to bring up graphics/network etc to
even just install so I don't know how we can get around this and still
have a device work enough to be able to install the needed firmware
across the network.

Ideas on how to solve that problem welcome.

Peter
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora and 5.19

[Peter Robinson]

On Thu, Aug 4, 2022 at 11:35 AM Hans de Goede  wrote:
>
> Hi,
>
> On 8/2/22 22:15, Justin Forbes wrote:
> > The initial fedora-5.19 branch has been created in kernel-ark. As I
> > mentioned earlier, F37 will branch a 6.0 merge window kernel, but that
> > will be replaced with 5.19 as soon as possible.
>
> I'm not sure when F37 branches of, but it would it not be better
> to keep at F37 on 5.19 and move rawhide to 6.0 once F37 has its
> own branch ?
>
> My main worry here is how you are going to get F37/rawhide consumers
> to move back from 5.20 to 5.19. The only way I see to do this is
> bump the epoch, which we generally try to avoid ?

dnf distro-sync will also downgrade but I two have concerns.

I wonder if not doing something similar to what we do when stabilising
kernels would work, push 5.19 to that and build there while keeping
rawhide branch as 5.20 rc and doing builds for it but not tagging it
into the rawhide release until branching. There might need to be a
special branch process there too. Messy for dev side but probably less
messy for uses.

Peter
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

[Peter Robinson]

On Mon, Jul 18, 2022 at 2:51 PM Prarit Bhargava  wrote:
>
> On 7/18/22 09:45, Justin Forbes wrote:
>
> >
> > There were unfortunately some corner cases with retbleed mitigation
> > that simply did not work. Most of those should have been worked out
> > over the past week, but due to the way the embargo was done, there was
> > a whole lot of testing that just couldn't happen before the code was
> > merged.  As this is your rebuild, the first thing I would do is see if
> > the proper fedora build boots on this system, and I would not work
> > with anything pre rc7 at this point. Doing so ensures that you are
> > missing valid fixes.  If the fedora build boots and your build does
> > not, that is an interesting case to investigate.  If the fedora build
> > does not, that should be filed as a bug and figured out as 5.19 will
> > be the F37 kernel.
>
> jforbes will there be an rc8 to handle the fallout of the retbleed changes?

Linus alludes to that in his rc7 announcement so yes:
https://lwn.net/Articles/901580/
___
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: aarch64 build failures in rawhide

[Peter Robinson]

On Fri, May 7, 2021 at 9:08 AM Martin Cermak  wrote:
>
> On  Fri  2021-05-07  09:43 , Florian Weimer wrote:
> > * Peter Robinson:
> >
> > > On Fri, May 7, 2021 at 7:58 AM Florian Weimer  wrote:
> > >>
> > >> We want to use kernel rebuilds as a gating test for toolchain updates.
> > >> Unfortunately, per
> > >>
> > >>   Information for package kernel
> > >>   <https://koji.fedoraproject.org/koji/packageinfo?packageID=8>
> > >>
> > >> the last successful rawhide kernel build was on 2021-04-28.
> > >>
> > >> The question is what we should do about build failures like this.
> > >> Should we use non-rawhide kernels for our gating tests?
> > >
> > > Well rawhide is generally OK, but it's not unusual for kernels to fail
> > > during the two week upstream merge window, I've seen all arches in x86
> > > cause issues during the merge window. Outside of that things tend to
> > > be OK.
> >
> > Hmm.  Currently our gating check simply does
> >
> >   koji build --scratch --wait --fail-fast f34-build-side-40913 
> > git+https://src.fedoraproject.org/rpms/kernel#rawhide
> >
> > (Well, it's a bug that we use the rawhide kernel branch on the f34
> > branch, but we'd still be impacted for actual rawhide builds of
> > toolchain packages, of course.)
> >
> > This koji command is nice and short, but it assumes that the dist-git
> > branch is actually buildable.
> >
> > Should we use a SRPM from a compose instead?  But composes can be really
> > old, and if we need a kernel fix to get things building again with newer
> > toolchains, then this could potentially block toolchain upgrades for a
> > long time.
>
>
> If I fedpkg clone the kernel repo (and switch to the appropriate
> branch) ... is there a way to identify (if not 100%, then at
> least with high probability) the latest commit that should be
> usable for the rebuild test?

You could query koji if the last build failed or not, and if it failed
how long ago that was. If it built OK in the last 24 hrs it's likely a
good indicator it's fine. The failures are mostly during the merge
window, so 2 weeks out of 10. You could also check if there's a
failure and if it's got rc0 in the NVR.
___
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: aarch64 build failures in rawhide

[Peter Robinson]

On Fri, May 7, 2021 at 7:58 AM Florian Weimer  wrote:
>
> We want to use kernel rebuilds as a gating test for toolchain updates.
> Unfortunately, per
>
>   Information for package kernel
>   
>
> the last successful rawhide kernel build was on 2021-04-28.
>
> The question is what we should do about build failures like this.
> Should we use non-rawhide kernels for our gating tests?

Well rawhide is generally OK, but it's not unusual for kernels to fail
during the two week upstream merge window, I've seen all arches in x86
cause issues during the merge window. Outside of that things tend to
be OK.

> (The bug appears to be in BTF generation: it is not valid to assume that
> static functions or variables are emitted under their declared names, or
> that they have any particular calling convention or data layout.  It's
> probably best to drop the static if symbols are used for BTF extraction.
> An alternative would be to use __attribute__ ((used)) instead, but then
> the linker won't check for name collisions, which would result in
> incorrect BTF.)

That issue is being dealt with upstream:
https://lore.kernel.org/bpf/20210427182053.ttiuxdt675lzm...@kafai-mbp.dhcp.thefacebook.com/T/#mb49c7d3d32700fa0e9c8b019fa3bf9d9e0cc3bf5
___
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: enable CONFIG_FW_LOADER_COMPRESS for ARK

[Peter Robinson]

On Mon, Mar 15, 2021 at 11:22 PM Herton R. Krzesinski (via Email
Bridge)  wrote:
>
> From: Herton R. Krzesinski 
>
> redhat: enable CONFIG_FW_LOADER_COMPRESS for ARK
>
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1939095
>
> The CONFIG_FW_LOADER_COMPRESS have been kept enabled only for Fedora.
> However in RHEL 9, we inherit the linux-firmware as is from Fedora, and
> it installs firmware files compressed in .xz format for RHEL too.
> However, the ARK/rhel config does not enable the needed support for
> loading compressed firmware files, and thus firmware loading fails.
>
> This fixes that by also enabling CONFIG_FW_LOADER_COMPRESS on ARK/rhel
> config too (since ARK and Fedora have the same setting now, the config
> file is moved to common/).
>
> Signed-off-by: Herton R. Krzesinski 

As the person who enabled it and has done the Fedora feature work
around the compressed firmware:
Reviewed-by: Peter Robinson 

> diff a/redhat/configs/ark/generic/CONFIG_FW_LOADER_COMPRESS 
> b/redhat/configs/ark/generic/CONFIG_FW_LOADER_COMPRESS
> --- a/redhat/configs/ark/generic/CONFIG_FW_LOADER_COMPRESS
> +++ /dev/null
> @@ -1 +0,0 @@
> -# CONFIG_FW_LOADER_COMPRESS is not set
> diff a/redhat/configs/fedora/generic/CONFIG_FW_LOADER_COMPRESS 
> b/redhat/configs/common/generic/CONFIG_FW_LOADER_COMPRESS
> --- a/redhat/configs/fedora/generic/CONFIG_FW_LOADER_COMPRESS
> +++ b/redhat/configs/common/generic/CONFIG_FW_LOADER_COMPRESS
>
> --
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/976
> ___
> 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
___
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] Make CONFIG_CRYPTO_DEV_QAT_* configs x86-only and unify them

[Peter Robinson]

On Thu, Mar 4, 2021 at 7:09 PM Vladis Dronov (via Email Bridge)
 wrote:
>
> From: Vladis Dronov 
>
> [redhat] Make CONFIG_CRYPTO_DEV_QAT_* configs x86-only and unify them
>
> Intel has confirmed that QAT hardware is x86 only. Unify all the related
> configs under redhat/configs/common/generic/x86/.

LGTM
Reviewed-by: Peter Robinson 

> Signed-off-by: Vladis Dronov 
>
> diff a/redhat/configs/common/generic/CONFIG_CRYPTO_DEV_QAT_4XXX 
> b/redhat/configs/common/generic/CONFIG_CRYPTO_DEV_QAT_4XXX
> --- a/redhat/configs/common/generic/CONFIG_CRYPTO_DEV_QAT_4XXX
> +++ /dev/null
> @@ -1 +0,0 @@
> -# CONFIG_CRYPTO_DEV_QAT_4XXX is not set
> diff a/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_4XXX 
> b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_4XXX
> --- /dev/null
> +++ b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_4XXX
> @@ -0,0 +1 @@
> +CONFIG_CRYPTO_DEV_QAT_4XXX=m
> diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_DEV_QAT_C3XXX 
> b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_C3XXX
> --- a/redhat/configs/ark/generic/CONFIG_CRYPTO_DEV_QAT_C3XXX
> +++ b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_C3XXX
> diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_DEV_QAT_C3XXXVF 
> b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_C3XXXVF
> --- a/redhat/configs/ark/generic/CONFIG_CRYPTO_DEV_QAT_C3XXXVF
> +++ b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_C3XXXVF
> diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_DEV_QAT_C62X 
> b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_C62X
> --- a/redhat/configs/ark/generic/CONFIG_CRYPTO_DEV_QAT_C62X
> +++ b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_C62X
> diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_DEV_QAT_C62XVF 
> b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_C62XVF
> --- a/redhat/configs/ark/generic/CONFIG_CRYPTO_DEV_QAT_C62XVF
> +++ b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_C62XVF
> diff a/redhat/configs/ark/generic/x86/x86_64/CONFIG_CRYPTO_DEV_QAT_DH895xCC 
> b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_DH895xCC
> --- a/redhat/configs/ark/generic/x86/x86_64/CONFIG_CRYPTO_DEV_QAT_DH895xCC
> +++ b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_DH895xCC
> diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_DEV_QAT_DH895xCCVF 
> b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_DH895xCCVF
> --- a/redhat/configs/ark/generic/CONFIG_CRYPTO_DEV_QAT_DH895xCCVF
> +++ b/redhat/configs/common/generic/x86/CONFIG_CRYPTO_DEV_QAT_DH895xCCVF
> diff a/redhat/configs/fedora/generic/CONFIG_CRYPTO_DEV_QAT_4XXX 
> b/redhat/configs/fedora/generic/CONFIG_CRYPTO_DEV_QAT_4XXX
> --- a/redhat/configs/fedora/generic/CONFIG_CRYPTO_DEV_QAT_4XXX
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -# CONFIG_CRYPTO_DEV_QAT_4XXX:
> -#
> -# Support for Intel(R) QuickAssist Technology QAT_4xxx
> -# for accelerating crypto and compression workloads.
> -#
> -# To compile this as a module, choose M here: the module
> -# will be called qat_4xxx.
> -#
> -# Symbol: CRYPTO_DEV_QAT_4XXX [=n]
> -# Type  : tristate
> -# Defined at drivers/crypto/qat/Kconfig:49
> -#   Prompt: Support for Intel(R) QAT_4XXX
> -#   Depends on: CRYPTO [=y] && CRYPTO_HW [=y] && X86 [=y] && PCI [=y]
> -#   Location:
> -# -> Cryptographic API (CRYPTO [=y])
> -#   -> Hardware crypto devices (CRYPTO_HW [=y])
> -# Selects: CRYPTO_DEV_QAT [=m]
> -#
> -#
> -#
> -CONFIG_CRYPTO_DEV_QAT_4XXX=m
> diff a/redhat/configs/fedora/generic/x86/CONFIG_CRYPTO_DEV_QAT_C3XXX 
> b/redhat/configs/fedora/generic/x86/CONFIG_CRYPTO_DEV_QAT_C3XXX
> --- a/redhat/configs/fedora/generic/x86/CONFIG_CRYPTO_DEV_QAT_C3XXX
> +++ /dev/null
> @@ -1 +0,0 @@
> -CONFIG_CRYPTO_DEV_QAT_C3XXX=m
> diff a/redhat/configs/fedora/generic/x86/CONFIG_CRYPTO_DEV_QAT_C3XXXVF 
> b/redhat/configs/fedora/generic/x86/CONFIG_CRYPTO_DEV_QAT_C3XXXVF
> --- a/redhat/configs/fedora/generic/x86/CONFIG_CRYPTO_DEV_QAT_C3XXXVF
> +++ /dev/null
> @@ -1 +0,0 @@
> -CONFIG_CRYPTO_DEV_QAT_C3XXXVF=m
> diff a/redhat/configs/fedora/generic/x86/CONFIG_CRYPTO_DEV_QAT_C62X 
> b/redhat/configs/fedora/generic/x86/CONFIG_CRYPTO_DEV_QAT_C62X
> --- a/redhat/configs/fedora/generic/x86/CONFIG_CRYPTO_DEV_QAT_C62X
> +++ /dev/null
> @@ -1 +0,0 @@
> -CONFIG_CRYPTO_DEV_QAT_C62X=m
> diff a/redhat/configs/fedora/generic/x86/CONFIG_CRYPTO_DEV_QAT_C62XVF 
> b/redhat/configs/fedora/generic/x86/CONFIG_CRYPTO_DEV_QAT_C62XVF
> --- a/redhat/configs/fedora/generic/x86/CONFIG_CRYPTO_DEV_QAT_C62XVF
> +++ /dev/null
> @@ -1 +0,0 @@
> -CONFIG_CRYPTO_DEV_QAT_C62XVF=m
> diff a/redhat/configs/fedora/generic/x86/CONFIG_CRYPTO_DEV_QAT_DH895xCC 
> b/redhat/configs/fedora/generic/x86/CONFIG

Re: [OS-BUILD PATCH 0/4] Drop stale pinephone patches

[Peter Robinson]

On Mon, Mar 1, 2021 at 5:51 PM Herton R. Krzesinski  wrote:
>
> On Wed, Feb 24, 2021 at 10:26:11PM -, Herton Krzesinski (via Email 
> Bridge) wrote:
> > From: Herton Krzesinski on gitlab.com
> > Merge Request: 
> > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/925
> >
> > Seems a while ago PinePhone patches not yet upstreamed where added.
> > However, some of them were reworked/dropped in its way upstream, and
> > this looks the final version that went in:
> > https://patchwork.freedesktop.org/series/79025/
> >
> > It got merged upstream through these commits:
> > 5f5df8b4253f12dbc0b9e328b3334ce28c16fc08^..c8a753484066a6382d2539d3dca14
> > 28164a682bf
> > a6a22f82c90dab8966fc07bd7e798a0680803995^..60f2de5ffbf0ed7c0d9789bcc1968
> > 84427e8cff5
> >
> > However, we still have some stale commits/patches that were not dropped
> > with the upstream merge. Remove them now.
> >
>
> Hi Lyude,
>
> can you review the patchset here, or through the merge request:
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/925
> And provide an ack or hit the approve button on the merge request.
>
> We still require an ack from drm folks, because some of the patches
> touches drm. It's just reverting patches that were dropped through its way
> upstream. We didn't have the ack/nack implementation we have now so that's
> why an ack was not required when these patches were included before.

These patches were added into Fedora for support for the device before
they were upstream and before Fedora was using the ARK process. Please
just drop them, they are no longer needed, I as the Fedora ARM kernel
maintainer has already ACKed 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [OS-BUILD PATCH 0/4] Drop stale pinephone patches

[Peter Robinson]

On Wed, Feb 24, 2021 at 10:26 PM Herton Krzesinski (via Email Bridge)
 wrote:
>
> From: Herton Krzesinski on gitlab.com
> Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/925
>
> Seems a while ago PinePhone patches not yet upstreamed where added.
> However, some of them were reworked/dropped in its way upstream, and
> this looks the final version that went in:
> https://patchwork.freedesktop.org/series/79025/
>
> It got merged upstream through these commits:
> 5f5df8b4253f12dbc0b9e328b3334ce28c16fc08^..c8a753484066a6382d2539d3dca14
> 28164a682bf
> a6a22f82c90dab8966fc07bd7e798a0680803995^..60f2de5ffbf0ed7c0d9789bcc1968
> 84427e8cff5
>
> However, we still have some stale commits/patches that were not dropped
> with the upstream merge. Remove them now.

Acked-by: Peter Robinson 

I tried to work out how to do this on ARK previously and gave up.
___
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: Ars claims: Fedora 32 is sluggish

[Peter Robinson]

On Thu, Feb 11, 2021 at 1:03 PM Ondrej Mosnacek  wrote:
>
> On Thu, Feb 11, 2021 at 10:14 AM Viktor Ashirov  wrote:
> > On Wed, Feb 3, 2021 at 5:54 PM Michael Catanzaro  
> > wrote:
> >>
> >> Hi,
> >>
> >> Has anybody investigated Jim Salter's claims that Fedora 32 is slow to
> >> launch applications? Recent article:
> >>
> >> https://arstechnica.com/gadgets/2021/02/ubuntu-core-20-adds-secure-boot-with-hardware-backed-encryption/
> >>
> >> "in my experience, Fedora 32 is noticeably, demonstrably more sluggish
> >> to launch applications than Ubuntu is in general."
> >>
> >> Original article:
> >>
> >> https://arstechnica.com/gadgets/2020/05/linux-distro-review-fedora-workstation-32/
> >>
> >> Would be good to know, for starters, whether this difference is real
> >> and measurable.
> >
> > This was bugging me for a while. I also noticed that Fedora 32 is a bit 
> > slower than it used to be. Compilation time of a project that I'm working 
> > on went from ~35-36 seconds to ~47-48. At first I thought that it's just 
> > another round of CPU vulnerabilities mitigations that introduced a 
> > performance drop. But after some digging I found that the default CPU 
> > governor was switched from 'ondemand' to 'schedutil' in Fedora kernel 5.9.7:
> > https://src.fedoraproject.org/rpms/kernel/c/73c86ebaee23df8310b903c1dab2176d443f5a3a?branch=rawhide
> > (see configs/fedora/generic/CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL)
> >
> > I switched it back using cpupower from kernel-tools:
> > $ sudo cpupower frequency-set --governor ondemand
> >
> > And confirmed that my compilation time went back to the previous ~35 
> > seconds.
> > In the end I switched the governor to 'performance' and shaved another 5 
> > seconds. And gnome-shell no longer feels sluggish, switching tabs in the 
> > browser is also instant.
> > To make the change permanent I used settings in /etc/sysconfig/cpupower and 
> > enabled cpupower service:
> > $ sudo systemctl enable --now cpupower.service
> >
> > The change of the default CPU governor looks pretty significant to me, but 
> > I couldn't find any discussions about it.
>
> CCing the Fedora kernel list and Justin. At the ARK tree level, the
> change was introduced in this commit, with no explanation:
> https://gitlab.com/cki-project/kernel-ark/commit/9d69ad49ab90db607e25a99eacbf31dc9e513dfa
>
> Justin, do you remember the reason for the change? Can/should it be reverted?

It was upstream changes, the Intel maintainer changed it in [1] if
X86_INTEL_PSTATE state was selected in late March which would make
sense in the timg, and also changed for arm arches [2] in July.

If that change was made upstream I'm assuming it was assumed that
performance should be equivalent or better than the other option, I
suspect we should engage with upstream as they're probably interested
in the issues.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a00ec3874e7d3
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f259eab3ea0e7
___
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: Latest 5.11 kernels are only build for rawhide/F35, not available for F34

[Peter Robinson]

> F34 has branched, so now, e.g. this kernel:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1706039
>
> Only has a fc35 tag and there is no 
> kernel-5.11.0-0.rc7.20210210gite0756cfc7d7c.150
> pkg with a fc34 tag.
>
> So I think we need a separate F34 build for this kernel, or at least for the
> next kernel.

F34 currently has kernel-5.11.0-0.rc7.149.fc34 and once we branch we
don't do debug builds on branched due to performance so from memory we
generally just get weekly rcX builds on branched kernels.
___
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] common: fix WM8804 codec dependencies

[Peter Robinson]

On Wed, Jan 13, 2021 at 8:43 AM Patrick Talbert  wrote:
>
> On Tue, Jan 12, 2021 at 12:24 PM GitLab Bridge on behalf of pbrobinson
>  wrote:
> >
> > From: Peter Robinson 
> >
> > The WM8804 codec is required for Intel Apollo Lake support so enable it
> > as it's a supported RHEL for Edge platform.
> >
> > Some minor cleanups for the WM8804 codec configs while we're at it.
> >
> > Signed-off-by: Peter Robinson 
> > ---
> >  .../generic/x86/CONFIG_SND_SOC_WM8804_I2C |  0
> >  .../fedora/generic/CONFIG_SND_SOC_WM8804  |  1 -
> >  .../fedora/generic/arm/CONFIG_SND_SOC_WM8804  |  1 -
> >  .../x86/CONFIG_SND_SOC_INTEL_SOF_WM8804_MACH  | 23 ---
> >  .../fedora/generic/x86/CONFIG_SND_SOC_WM8804  |  1 -
> >  5 files changed, 26 deletions(-)
> >  rename redhat/configs/{fedora => 
> > common}/generic/x86/CONFIG_SND_SOC_WM8804_I2C (100%)
> >  delete mode 100644 redhat/configs/fedora/generic/CONFIG_SND_SOC_WM8804
> >  delete mode 100644 redhat/configs/fedora/generic/arm/CONFIG_SND_SOC_WM8804
> >  delete mode 100644 
> > redhat/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_WM8804_MACH
> >  delete mode 100644 redhat/configs/fedora/generic/x86/CONFIG_SND_SOC_WM8804
> >
> > diff --git a/redhat/configs/fedora/generic/x86/CONFIG_SND_SOC_WM8804_I2C 
> > b/redhat/configs/common/generic/x86/CONFIG_SND_SOC_WM8804_I2C
> > similarity index 100%
> > rename from redhat/configs/fedora/generic/x86/CONFIG_SND_SOC_WM8804_I2C
> > rename to redhat/configs/common/generic/x86/CONFIG_SND_SOC_WM8804_I2C
> > diff --git a/redhat/configs/fedora/generic/CONFIG_SND_SOC_WM8804 
> > b/redhat/configs/fedora/generic/CONFIG_SND_SOC_WM8804
> > deleted file mode 100644
> > index 074702b5ef5e..
> > --- a/redhat/configs/fedora/generic/CONFIG_SND_SOC_WM8804
> > +++ /dev/null
> > @@ -1 +0,0 @@
> > -# CONFIG_SND_SOC_WM8804 is not set
> > diff --git a/redhat/configs/fedora/generic/arm/CONFIG_SND_SOC_WM8804 
> > b/redhat/configs/fedora/generic/arm/CONFIG_SND_SOC_WM8804
> > deleted file mode 100644
> > index 04b89d9ff78b..
> > --- a/redhat/configs/fedora/generic/arm/CONFIG_SND_SOC_WM8804
> > +++ /dev/null
> > @@ -1 +0,0 @@
> > -CONFIG_SND_SOC_WM8804=m
> > diff --git 
> > a/redhat/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_WM8804_MACH 
> > b/redhat/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_WM8804_MACH
> > deleted file mode 100644
> > index bb7ee45866a6..
> > --- a/redhat/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_WM8804_MACH
> > +++ /dev/null
> > @@ -1,23 +0,0 @@
> > -# CONFIG_SND_SOC_INTEL_SOF_WM8804_MACH:
> > -#
> > -# This adds support for ASoC machine driver for Intel platforms
> > -# with the Wolfson/Cirrus WM8804 I2S audio codec.
> > -# Say Y or m if you have such a device. This is a recommended option.
> > -# If unsure select "N".
> > -#
> > -# Symbol: SND_SOC_INTEL_SOF_WM8804_MACH [=n]
> > -# Type  : tristate
> > -# Defined at sound/soc/intel/boards/Kconfig:329
> > -#   Prompt: SOF with Wolfson/Cirrus WM8804 codec
> > -#   Depends on: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && 
> > SND_SOC_INTEL_MACH [=y] && SND_SOC_SOF_APOLLOLAKE [=m] && I2C [=y] && ACPI 
> > [=y] && (MFD_INTEL_LPSS [=y] || COMPILE_TEST [=n])
> > -#   Location:
> > -# -> Device Drivers
> > -#   -> Sound card support (SOUND [=m])
> > -# -> Advanced Linux Sound Architecture (SND [=m])
> > -#   -> ALSA for SoC audio support (SND_SOC [=m])
> > -# -> Intel Machine drivers (SND_SOC_INTEL_MACH [=y])
> > -# Selects: SND_SOC_WM8804_I2C [=n]
> > -#
> > -#
> > -#
> > -CONFIG_SND_SOC_INTEL_SOF_WM8804_MACH=m
> > diff --git a/redhat/configs/fedora/generic/x86/CONFIG_SND_SOC_WM8804 
> > b/redhat/configs/fedora/generic/x86/CONFIG_SND_SOC_WM8804
> > deleted file mode 100644
> > index 04b89d9ff78b..
> > --- a/redhat/configs/fedora/generic/x86/CONFIG_SND_SOC_WM8804
> > +++ /dev/null
> > @@ -1 +0,0 @@
> > -CONFIG_SND_SOC_WM8804=m
> > --
> > GitLab
> >
>
> Jaroslav can you give your input here please?

I was going to rebase this on top of the other change that just went
in, I hadn't seen that PR when I submitted 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: [OS-BUILD PATCHv4 2/2] Update CONFIG_ARM_CMN based on comment

[Peter Robinson]

On Tue, Dec 22, 2020 at 4:24 PM GitLab Bridge on behalf of jeremycline
 wrote:
>
> From: "Justin M. Forbes" 
>
> Signed-off-by: Justin M. Forbes 
Reviewed-by: Peter Robinson 

> Cc: Mark Salter 
> Cc: Mark Langsdorf 
> Cc: Jeremy Linton 
> ---
>  redhat/configs/common/generic/CONFIG_ARM_CMN | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/redhat/configs/common/generic/CONFIG_ARM_CMN 
> b/redhat/configs/common/generic/CONFIG_ARM_CMN
> index 08b81d7dcde5..c0cb7f71b493 100644
> --- a/redhat/configs/common/generic/CONFIG_ARM_CMN
> +++ b/redhat/configs/common/generic/CONFIG_ARM_CMN
> @@ -1 +1 @@
> -# CONFIG_ARM_CMN is not set
> +CONFIG_ARM_CMN=m
> --
> 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
___
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: [NIT] error: %changelog not in descending chronological order

[Peter Robinson]

On Mon, Dec 28, 2020 at 6:58 PM Justin Forbes  wrote:
>
> On Mon, Dec 28, 2020 at 12:10 PM Paul Bolle  wrote:
> >
> > Hi Justin,
> >
> > Nobody noticed, so this is just a nit, but ever since the v5.8.14 build for
> > fc32 there's this in the fc32 build logs:
> >  error: %changelog not in descending chronological order
> >
> > I think what triggers this is that you've recently added extended the
> > datestamp on your changelog entries with timestamps. Eg:
> > * Wed Oct  7 07:21:23 CDT 2020 Justin M. Forbes 
> >  - 5.8.14-200
>
> Yes, this is what triggers it, and it is added by a change in
> rpmdev-bumpspec in F33.   I was kind of hoping that rpm would also be
> changed to ignore this, so I have not done anything about it.  I
> suppose I could look into it, but it is just noise at the moment.
>
> >
> > But if the preceding changelog entry doesn't have a timestamp, like:
> > * Wed Oct  7 2020 Peter Robinson 
> >
> > rpmbuild spits out an "error:" but merrily continues the build! (I have no
> > idea how that works. Both the timestamp comparison and the build ignoring an
> > error.)
> >
> > Do people care enough to try to fix this?
>
> With the cause coming from a change in rpmdev-bumpspec, I am guessing
> that kernel is not the only package to notice it, though we do use
> scripts calling it more than most I suppose.  I may look into it, but
> from a tooling standpoint, we will likely end up changing a lot of
> scripts, so it is fairly low priority at the moment.

The change is due to be reverted to the old date method, details in
https://pagure.io/rpmdevtools/issue/63
___
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 3/3] redhat/configs/ark: Enable CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL

[Peter Robinson]

On Wed, Dec 9, 2020 at 5:55 PM Josh Poimboeuf  wrote:
>
> On Wed, Dec 09, 2020 at 08:52:08AM +, Peter Robinson wrote:
> > On Tue, Dec 8, 2020 at 9:52 PM GitLab Bridge on behalf of jpoimboe
> >  wrote:
> > >
> > > From: Josh Poimboeuf 
> > >
> > > Enable CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL for ark.  This prevents a
> > > lot of uninitialized stack variable exploits, with a minimal impact on
> > > performance.
> >
> > Is there any reason to do this purely in ARK and not in the common config?
>
> I don't know of any reason not to make this change in Fedora, but
> wouldn't that would be up to the Fedora kernel maintainers?

Yes, but they also participate here and can ACK the change as well.
___
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 2/3] redhat/configs/ark: Enable CONFIG_GCC_PLUGIN_STRUCTLEAK

[Peter Robinson]

On Tue, Dec 8, 2020 at 9:52 PM GitLab Bridge on behalf of jpoimboe
 wrote:
>
> From: Josh Poimboeuf 
>
> This will be needed for CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL.

Is there any point in having it on it's own then and not as part of
that commit so it's all together?

> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1856176
> Signed-off-by: Josh Poimboeuf 
> ---
>  redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 100644 redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK
>
> diff --git a/redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK 
> b/redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK
> new file mode 100644
> index ..ea3aac683cd6
> --- /dev/null
> +++ b/redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK
> @@ -0,0 +1 @@
> +CONFIG_GCC_PLUGIN_STRUCTLEAK=y
> --
> 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
___
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 3/3] redhat/configs/ark: Enable CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL

[Peter Robinson]

On Tue, Dec 8, 2020 at 9:52 PM GitLab Bridge on behalf of jpoimboe
 wrote:
>
> From: Josh Poimboeuf 
>
> Enable CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL for ark.  This prevents a
> lot of uninitialized stack variable exploits, with a minimal impact on
> performance.

Is there any reason to do this purely in ARK and not in the common config?

> This feature is incompatible with CONFIG_KASAN, so it can't be enabled
> on debug kernels.
>
> Also, it's mutually exclusive with CONFIG_INIT_STACK_NONE=y.
>
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1856176
> Signed-off-by: Josh Poimboeuf 
> ---
>  .../generic => ark/debug}/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL | 0
>  .../configs/{common/generic => ark/debug}/CONFIG_INIT_STACK_NONE | 0
>  .../configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL   | 1 +
>  redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE  | 1 +
>  redhat/configs/ark/generic/CONFIG_INIT_STACK_NONE| 1 +
>  .../fedora/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL| 1 +
>  redhat/configs/fedora/generic/CONFIG_INIT_STACK_NONE | 1 +
>  7 files changed, 5 insertions(+)
>  rename redhat/configs/{common/generic => 
> ark/debug}/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL (100%)
>  rename redhat/configs/{common/generic => ark/debug}/CONFIG_INIT_STACK_NONE 
> (100%)
>  create mode 100644 
> redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
>  create mode 100644 
> redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE
>  create mode 100644 redhat/configs/ark/generic/CONFIG_INIT_STACK_NONE
>  create mode 100644 
> redhat/configs/fedora/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
>  create mode 100644 redhat/configs/fedora/generic/CONFIG_INIT_STACK_NONE
>
> diff --git 
> a/redhat/configs/common/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL 
> b/redhat/configs/ark/debug/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
> similarity index 100%
> rename from 
> redhat/configs/common/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
> rename to redhat/configs/ark/debug/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
> diff --git a/redhat/configs/common/generic/CONFIG_INIT_STACK_NONE 
> b/redhat/configs/ark/debug/CONFIG_INIT_STACK_NONE
> similarity index 100%
> rename from redhat/configs/common/generic/CONFIG_INIT_STACK_NONE
> rename to redhat/configs/ark/debug/CONFIG_INIT_STACK_NONE
> diff --git 
> a/redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL 
> b/redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
> new file mode 100644
> index ..1713b5628e90
> --- /dev/null
> +++ b/redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
> @@ -0,0 +1 @@
> +CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y
> diff --git a/redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE 
> b/redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE
> new file mode 100644
> index ..321ed2054eca
> --- /dev/null
> +++ b/redhat/configs/ark/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE
> @@ -0,0 +1 @@
> +# CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE is not set
> diff --git a/redhat/configs/ark/generic/CONFIG_INIT_STACK_NONE 
> b/redhat/configs/ark/generic/CONFIG_INIT_STACK_NONE
> new file mode 100644
> index ..37f7832f62d2
> --- /dev/null
> +++ b/redhat/configs/ark/generic/CONFIG_INIT_STACK_NONE
> @@ -0,0 +1 @@
> +# CONFIG_INIT_STACK_NONE is not set
> diff --git 
> a/redhat/configs/fedora/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL 
> b/redhat/configs/fedora/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
> new file mode 100644
> index ..83bd543915b6
> --- /dev/null
> +++ b/redhat/configs/fedora/generic/CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
> @@ -0,0 +1 @@
> +# CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL is not set
> diff --git a/redhat/configs/fedora/generic/CONFIG_INIT_STACK_NONE 
> b/redhat/configs/fedora/generic/CONFIG_INIT_STACK_NONE
> new file mode 100644
> index ..16e74023a918
> --- /dev/null
> +++ b/redhat/configs/fedora/generic/CONFIG_INIT_STACK_NONE
> @@ -0,0 +1 @@
> +CONFIG_INIT_STACK_NONE=y
> --
> 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
___
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 1/2] kernel: Enable coresight on aarch64

[Peter Robinson]

On Tue, Dec 8, 2020 at 4:51 PM GitLab Bridge on behalf of jlinton
 wrote:
>
> From: Jeremy Linton 
>
> Coresight is a hardware assisted debug and trace technology.
> Now that 5.10 allows them to be built as modules lets
> enable the functionality in fedora.
>
> More information about coresight may be found here:
>
> https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace
>
> Signed-off-by: Jeremy Linton 
Reviewed-by: Peter Robinson 

Generally LGTM from a Fedora aarch64 PoV, I know this functionality
was being reviewed for RHEL, so should it go into
redhat/configs/common/ instead?

Peter

> ---
>  redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT   | 1 +
>  redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_CATU  | 1 +
>  .../fedora/generic/arm/aarch64/CONFIG_CORESIGHT_CPU_DEBUG| 1 +
>  redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_CTI   | 1 +
>  .../generic/arm/aarch64/CONFIG_CORESIGHT_CTI_INTEGRATION_REGS| 1 +
>  .../fedora/generic/arm/aarch64/CONFIG_CORESIGHT_LINKS_AND_SINKS  | 1 +
>  .../generic/arm/aarch64/CONFIG_CORESIGHT_LINK_AND_SINK_TMC   | 1 +
>  .../fedora/generic/arm/aarch64/CONFIG_CORESIGHT_SINK_ETBV10  | 1 +
>  .../fedora/generic/arm/aarch64/CONFIG_CORESIGHT_SINK_TPIU| 1 +
>  .../fedora/generic/arm/aarch64/CONFIG_CORESIGHT_SOURCE_ETM4X | 1 +
>  redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_STM   | 1 +
>  .../configs/fedora/generic/arm/aarch64/CONFIG_PID_IN_CONTEXTIDR  | 1 +
>  redhat/configs/fedora/generic/arm/aarch64/CONFIG_STM | 1 +
>  redhat/configs/fedora/generic/arm/aarch64/CONFIG_STM_DUMMY   | 1 +
>  redhat/configs/fedora/generic/arm/aarch64/CONFIG_STM_PROTO_BASIC | 1 +
>  redhat/configs/fedora/generic/arm/aarch64/CONFIG_STM_PROTO_SYS_T | 1 +
>  .../configs/fedora/generic/arm/aarch64/CONFIG_STM_SOURCE_CONSOLE | 1 +
>  .../configs/fedora/generic/arm/aarch64/CONFIG_STM_SOURCE_FTRACE  | 1 +
>  .../fedora/generic/arm/aarch64/CONFIG_STM_SOURCE_HEARTBEAT   | 1 +
>  19 files changed, 19 insertions(+)
>  create mode 100644 redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_CATU
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_CPU_DEBUG
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_CTI
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_CTI_INTEGRATION_REGS
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_LINKS_AND_SINKS
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_LINK_AND_SINK_TMC
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_SINK_ETBV10
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_SINK_TPIU
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_SOURCE_ETM4X
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_STM
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_PID_IN_CONTEXTIDR
>  create mode 100644 redhat/configs/fedora/generic/arm/aarch64/CONFIG_STM
>  create mode 100644 redhat/configs/fedora/generic/arm/aarch64/CONFIG_STM_DUMMY
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_STM_PROTO_BASIC
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_STM_PROTO_SYS_T
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_STM_SOURCE_CONSOLE
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_STM_SOURCE_FTRACE
>  create mode 100644 
> redhat/configs/fedora/generic/arm/aarch64/CONFIG_STM_SOURCE_HEARTBEAT
>
> diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT 
> b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT
> new file mode 100644
> index ..4d70504d87d4
> --- /dev/null
> +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT
> @@ -0,0 +1 @@
> +CONFIG_CORESIGHT=m
> diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_CATU 
> b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_CATU
> new file mode 100644
> index ..160c1a367bad
> --- /dev/null
> +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_CATU
> @@ -0,0 +1 @@
> +CONFIG_CORESIGHT_CATU=m
> diff --git 
> a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_CPU_DEBUG 
> b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_CORESIGHT_CPU_DEBUG
> new file mode 100644
> index ..05ee4b1530f6
> --- /dev/null
> +++ b/redhat/configs/fe

Re: [OS-BUILD PATCH] redhat: ark: enable CONFIG_IKHEADERS

[Peter Robinson]

On Thu, Nov 26, 2020 at 6:24 PM GitLab Bridge on behalf of Jiri Olsa
 wrote:
>
> From: Jiri Olsa on gitlab.com
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/774#note_455681451
>
> >
> >
> >
> > CKI Gitlab commented:
> >
> >
> > Peter Robinson  commented via email:
> > ```
> > >
> > > > > IIUC that seems like some big reorg change that I'm not
> competent
> > > > > to do..
> > > >
> > > > You are :-)
> > > >
> > > > > I just need to add an option to ark kernel
> > > >
> > > > ARK inherits from common. We're trying to have as few files in
> configs/
> > > > as possible. If something is the same (or becomes the same) in ARK
> and
> > > > Fedora, it goes to configs/common/.
> > >
> > > ok, there goes the quick small change I was hoping for ;-)
> >
> > It's literally a couple of "git mv" commands, it's not large
>
> ok, so you do it ;-)

And exactly how do you learn from 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

Re: [OS-BUILD PATCH] redhat: ark: enable CONFIG_IKHEADERS

[Peter Robinson]

On Thu, Nov 26, 2020 at 4:25 PM Jiri Olsa  wrote:
>
> On Thu, Nov 26, 2020 at 04:56:13PM +0100, Jiri Benc wrote:
> > On Thu, 26 Nov 2020 15:46:17 -, GitLab Bridge on behalf of Jiri Olsa 
> > wrote:
> > > IIUC that seems like some big reorg change that I'm not competent
> > > to do..
> >
> > You are :-)
> >
> > > I just need to add an option to ark kernel
> >
> > ARK inherits from common. We're trying to have as few files in configs/
> > as possible. If something is the same (or becomes the same) in ARK and
> > Fedora, it goes to configs/common/.
>
> ok, there goes the quick small change I was hoping for ;-)

It's literally a couple of "git mv" commands, it's not large
___
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] redhat: ark: enable CONFIG_IKHEADERS

[Peter Robinson]

On Thu, Nov 26, 2020 at 12:33 PM GitLab Bridge on behalf of jolsa1
 wrote:
>
> From: Jiri Olsa 
>
> Enabling kheaders module that carries kernel headers
> to compile eBPF programs and will allow bcc-tools rpm
> to get rid of kernel-devel dependency.
>
> Signed-off-by: Jiri Olsa 
> ---
>  redhat/configs/ark/generic/CONFIG_IKHEADERS| 2 +-
>  redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_IKHEADERS | 1 +

Please just move redhat/configs/fedora/generic/ to
redhat/configs/common/generic/ and then delete the redhat/configs/ark
ones

>  2 files changed, 2 insertions(+), 1 deletion(-)
>  create mode 100644 redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_IKHEADERS
>
> diff --git a/redhat/configs/ark/generic/CONFIG_IKHEADERS 
> b/redhat/configs/ark/generic/CONFIG_IKHEADERS
> index e214495e0279..e96a93bd406a 100644
> --- a/redhat/configs/ark/generic/CONFIG_IKHEADERS
> +++ b/redhat/configs/ark/generic/CONFIG_IKHEADERS
> @@ -1 +1 @@
> -# CONFIG_IKHEADERS is not set
> +CONFIG_IKHEADERS=m
> diff --git a/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_IKHEADERS 
> b/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_IKHEADERS
> new file mode 100644
> index ..e214495e0279
> --- /dev/null
> +++ b/redhat/configs/ark/generic/s390x/zfcpdump/CONFIG_IKHEADERS
> @@ -0,0 +1 @@
> +# CONFIG_IKHEADERS is not set
> --
> 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
___
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 CONFIG_ACPI_TABLE_UPGRADE in Fedora kernels

[Peter Robinson]

> I believe $subject has been discussed before but I would like to see us
> reconsider this.
>
> I know that the general rule of thumb is that DSDTs should not be overriden
> and instead the kernel should be made to "just work" with existing DSDTs
> even if they are buggy. And as someone who does a lot of ACPI related
> bug-fixing in the upstream kernel, I completely agree.
>
> IIRC this was the main argument against enabling CONFIG_ACPI_TABLE_UPGRADE,
> but even with it enabled actually using this is far from easy, so I'm
> NOT worried that this will cause uses to do DSDT overrides to paper over
> bugs which we really should fix otherwise.
>
> But sometimes being able to override the DSDT is still useful:
>
> 1. When I'm helping users to get various hardware issues fixed sometimes
> it is useful to given them a DSDT override changing e.g. the bus-speed
> for an I2C bus, or changing the type of an IRQ from level to edge, etc.
>
> 2. Unfortunately there is a small number of DSDT bugs which the kernel
> simply cannot be fixed to handle. I know at least 2 examples of this:
>
> Example a. The Onda v975w ACPI battery code has a bug where the
> full capacity always reports 0. This is a very straight forward error
> in the DSDT, not a case of using some wiggle room in the ACPI spec
> (expecting certain behavior which only Windows shows). This is
> simply a DSDT bug. The code might just a well say "return 0"
>
> Example b. The Acer Switch sw5-012 is completely missing the ACPI
> Device (PWM0) section declaring the PWM controller which is used
> for controlling the backlight of the LCD. This leads to non working
> brightness control and also to much to high energy drain while
> suspended.
>
> For both these cases having CONFIG_ACPI_TABLE_UPGRADE=y would be
> very helpful. The only downside would be that this is not compatible
> with secureboot. So if not done upstream already then we must tie
> this to the kernel-lockdown stuff and disallow it when lockdown mode
> is active. I can try to write a patch for this if necessary.

I think disabling this for secure boot/lockdown makes sense because
there's likely security implications to this. I seem to remember this
was one of the reasons for previously not enabling it.
___
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

Fwd: heads up regarding some v5.10 changes

[Peter Robinson]

FYI:

-- Forwarded message -
From: Ard Biesheuvel 
Date: Sat, Oct 31, 2020 at 10:22 AM
Subject: heads up regarding some v5.10 changes
To: , Arnd Bergmann ,
Peter Jones 


Hello all,

Just a note to whomever is subscribed to this list regarding some
changes in v5.10 that may affect distros' kernel deployments:

efivars
---
efivars is the ancient predecessor to efivarFs, that allows access to
EFI variables via sysfs (but with some restrictions). This has been
deprecated since before ARM even had UEFI support, and it is no longer
going to be enabled going forward. EFI pstore has been rewritten to no
longer rely on it, and on x86, the module is still available, but no
longer gets loaded automatically. On !x86, it is no longer built at
all. As far as I could figure out (and I did ask around as well), this
is highly unlikely to regress anything, and on x86, the module can
still be loaded manually if needed (or enabled as a builtin)

deprecated crypto
-
Some crypto drivers have been made to depend on
CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE, which is only available if the
crypto AF_ALG socket API is enabled, as the algorithms are never used
by the kernel itself. However, none of these ciphers are known to be
relied upon by user space either (via AF_ALG), and so I strongly
recommend the distros incorporate

# CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set

into their v5.10+ kernel configs so that these deprecated algorithms
are simply dropped from the build (the algos are arc4, tea, khazad,
SEED and anubis, others may follow in the future, e.g., md4/5). Note
that iwd/libell used to rely on the kernel's ecb(arc4) implementation,
but this is no longer the case.

kexec/kdump tools
---
To make the kernel's PE/COFF header spec compliant, the stext symbol
will be aligned to 64 KB regardless of the page size the kernel was
built with. As far as I can tell looking at the debian source of the
associated tooling, the symbol value of stext is used to infer the
page size, so this will no longer work.
___
cross-distro mailing list
cross-dis...@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/cross-distro
___
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: about NVIDIA Driver not yet supported for Linux Kernel 5.9+

[Peter Robinson]

> First I'd like alert for this issue [1] with kernel 5.9 , and asking if
> somehow we can delay kernel 5.9 on stable branches ?

You could just exclude the kernel from updates for local affected devices.

> Best regards
>
> [1]
> https://forums.developer.nvidia.com/t/nvidia-driver-not-yet-supported-for-linux-kernel-5-9/157263
>
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Blocking-NV-NetGPU
>
> https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Linux-5.9-Delayed
>
> --
> Sérgio M. B.
> ___
> 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: [OS-BUILD PATCH] [redhat] New configs in net/can

[Peter Robinson]

On Mon, Oct 19, 2020 at 6:29 PM Marcelo Ricardo Leitner
 wrote:
>
> On Mon, Oct 19, 2020 at 06:19:39PM +0100, Peter Robinson wrote:
> > On Mon, Oct 19, 2020 at 5:33 PM Marcelo Ricardo Leitner
> >  wrote:
> > >
> > > On Fri, Oct 16, 2020 at 03:29:56PM -, GitLab Bridge on behalf of 
> > > jeremycline wrote:
> > > > --- /dev/null
> > > > +++ b/redhat/configs/common/generic/CONFIG_CAN_ISOTP
> > > > @@ -0,0 +1 @@
> > > > +# CONFIG_CAN_ISOTP is not set
> > >
> > > I'm not aware of any reason for it to be enabled, so
> >
> > Reading the description [1] if CAN is enabled you likely do want to
> > enable it as it enables the ability to segment up packages to support
> > protocols like IP over CAN.
>
> This "likely" varies. I understand that it adds functionality, yes,
> but enabling it means extra work to support it and I'm not aware of
> any use case for it with RHEL. For Fedora that may be a different
> story, but then I expect someone more Fedora-centric to chime in.

I think it should be reviewed for RHEL, the RHEL for Edge initiative
has CAN on it's roadmap amongst other things in the el9 timeframe. If
you''re enabling CAN it should be functional for the majority of
useful usecases or just disable it completely.
___
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] [redhat] New configs in net/can

[Peter Robinson]

On Mon, Oct 19, 2020 at 5:33 PM Marcelo Ricardo Leitner
 wrote:
>
> On Fri, Oct 16, 2020 at 03:29:56PM -, GitLab Bridge on behalf of 
> jeremycline wrote:
> > --- /dev/null
> > +++ b/redhat/configs/common/generic/CONFIG_CAN_ISOTP
> > @@ -0,0 +1 @@
> > +# CONFIG_CAN_ISOTP is not set
>
> I'm not aware of any reason for it to be enabled, so

Reading the description [1] if CAN is enabled you likely do want to
enable it as it enables the ability to segment up packages to support
protocols like IP over CAN.

Peter

[1] https://cateee.net/lkddb/web-lkddb/CAN_ISOTP.html
___
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: Guidance regarding BUG 1821946

[Peter Robinson]

On Tue, Sep 22, 2020 at 12:04 AM Paulo Edgar Castro
 wrote:
>
> Hi folks,
>
> Any ETA on this bug https://bugzilla.redhat.com/show_bug.cgi?id=1821946
>
> or guidance regarding this
>
> ```
>
> [root@localhost ~]# dnf install kernel-headers-$(uname -r) 2>/dev/null
> Last metadata expiration check: 0:00:15 ago on Tue 22 Sep 2020 00:02:27 BST.
> No match for argument: kernel-headers-5.8.10-200.fc32.x86_64
> [root@localhost ~]# uname -r
> 5.8.10-200.fc32.x86_64

The headers package is only updated when it changes, as it generally
doesn't change much in a stable cycle, so you should just do "dnf
install kernel-headers"
___
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: How to get fixes added to f* / stable distgit branches ?

[Peter Robinson]

The ARK process isn't used for Fedora stable, just rawhide.

For Fedora stable just push direct to the Fedora package git repo like before.

P

On Thu, Sep 17, 2020 at 10:32 AM Hans de Goede  wrote:
>
> Hi All,
>
> With the new ARK way of doing things, I know that if I want to get patches 
> added to
> the rawhide kernel I need to do this through a merge-req to:
> https://gitlab.com/cki-project/kernel-ark
>
> But what is the way to get patches added to say the 5.8.9 kernel for the
> f31 - f33 distgit branches?
>
> Is it still git add the patch, add to .spec, add a changelog
> entry without a EVR added to the changelog entry and wait for it
> to get picked up by the next f## kernel build ?
>
> Note the reason why I'm asking is because the 5.8 kernels have a nasty
> regression causing the builtin keyboard and touchpad to not work
> on many Asus laptops.
>
> As I'm not entirely sure how to add the patch fixing this, I will
> send it to the list in a separate patch. It would be good if this
> can get added to the Fedora 31-33 5.8 kernels ASAP. The fixes should
> get added to the next 5.9-rc# release, so for 5.9 we should be good
> but I will keep an eye on this to make sure.
>
> Regards,
>
> Hans
> ___
> 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: Fedora kernels >= 5.8 have xhci-pci build as a module

[Peter Robinson]

On Wed, Sep 2, 2020 at 4:08 PM Hans de Goede  wrote:
>
> Hi All,
>
> 5.8 introduces a new CONFIG_USB_XHCI_PCI_RENESAS Kconfig symbol.
>
> The current Fedora kernel config says this to 'm'. I assume that
> this was done because the help-text suggests that doing so will
> make support for some special XHCI controllers which need to
> be "booted" (have firmware loaded) by the kernel modular, while
> keeping the generic xhci-pci code builtin so that we start probing
> XHCI USB busses ASAP during boot.
>
> But, and this is somewhat of a surprise, the xhci-pci-renesas
> code does not use the xhci-pci code as a library on top of
> which it builds. Instead it offers some hooks for the xhci-pci
> code to call in and having CONFIG_USB_XHCI_PCI_RENESAS set will
> thus make xhci-pci.ko depend on xhci-pci-renesas.ko.
>
> Which means that if xhci-pci-renesas.ko is not builtin, this
> also forces xhci-pci.ko to not be builtin.
>
> As said I assume that this xhci-pci.ko no longer being builtin
> is not intentional, so that the right way to fix this would
> be to set CONFIG_USB_XHCI_PCI_RENESAS=y, right ?

We don't need to enable CONFIG_USB_XHCI_PCI_RENESAS because we don't
enable ARCH_RENESAS, if that controller has some weirdisms upstream
likely should have made it something like "default y if ARCH_RENESAS"
or similar.

> This problem is leading to some people not being able to
> enter their disk passwords, see:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1874300
>
> Regards,
>
> Hans
> ___
> 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: [OS-BUILD PATCHv2 0/3] configs: Enable CONFIG_ENERGY_MODEL

[Peter Robinson]

> > From: prauld on gitlab.com
> >
> > CONFIG_ENERGY_MODEL will help make the schedutil frequency governor
> > more accurate. This will be useful in the future. It also enables
> > the use of the energy aware scheduler.
> >
> > Signed-off-by: Phil Auld 
>
> pauld, I was looking at this config the other day.  I was wondering if it
> changes the existing default scheduler choice?

It's been on my list to investigate for Fedora as well.
___
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] kernel: coresight: Enable coresight decoding

[Peter Robinson]

I've pushed this to the Fedora rawhide kernel-tools package, it'll
appear in the next build.

Peter

On Tue, Jul 14, 2020 at 7:12 PM Jeremy Linton  wrote:
>
> Perf is capable of decoding coresite debug/trace files
> but the feature needs to be enabled with CORESIGHT=1
> and the decode library needs to be added as a build
> dependency.
>
> Signed-off-by: Jeremy Linton 
> ---
>  kernel.spec | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel.spec b/kernel.spec
> index e60421066..235e5587f 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -494,6 +494,7 @@ BuildRequires: sparse
>  BuildRequires: zlib-devel binutils-devel newt-devel perl(ExtUtils::Embed) 
> bison flex xz-devel
>  BuildRequires: audit-libs-devel
>  BuildRequires: java-devel
> +BuildRequires: opencsd-devel
>  %ifnarch %{arm} s390x
>  BuildRequires: numactl-devel
>  %endif
> @@ -2100,7 +2101,7 @@ BuildKernel %make_target %kernel_image %{_use_vdso}
>  %endif
>
>  %global perf_make \
> -  %{__make} -s EXTRA_CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" 
> %{?cross_opts} -C tools/perf V=1 NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 
> WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 
> NO_BIONIC=1 prefix=%{_prefix} PYTHON=%{__python3}
> +  %{__make} -s EXTRA_CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" 
> %{?cross_opts} -C tools/perf V=1 NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 
> WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 
> NO_BIONIC=1 CORESIGHT=1 prefix=%{_prefix} PYTHON=%{__python3}
>  %if %{with_perf}
>  # perf
>  # make sure check-headers.sh is executable
> --
> 2.27.0
>
___
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/17] rebase Pinephone screen patches

[Peter Robinson]

> Ah, ok.  Yeah, I discussed with Justin awhile ago, about just taking patches
> for Fedora from folks he trusted were taking upstream committed patches
> because that is the speed Fedora is used to.  I will chat with Red Hat folks
> about what can be done to not get in the way.

Well I'm been doing the arm/aarch64 kernel maintenance for around 8 years.

> In general the concern is to make sure non-upstream'd accepted patches get 
> reviewed.

In some cases I regularly rebase some patches that are evolving
upstream, if you look at the reverted patches vs the new ones they are
widely different based on upstream as the patches have evolved.

> So pointing to upstream commits is the easiest way to reduce that concern
> (at least submaintainer commit ids as those will be the same in Linus's

Yes, when there is upstream I usually would, the new way of doing
things is weird, do I do it in the MR, do I have to manually edit
every single patch to add RHEMisms? I do this stuff in my spare time,
this is laborious ATM compared to the old work flow.

> Patchwork patches don't have those ids, but I would think they are in an
> arm-next branch or something??

There's a newer version of these patches upstream because the
drm-misc-next where some of them have landed had other changes and
they needed a rebase. In the past this was documented in the
kernel.spec.

> I will work on some ideas to not negatively impact your contributions.
>
> Thanks!
>
> Cheers,
> Don
>
___
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/17] rebase Pinephone screen patches

[Peter Robinson]

> On Sun, Jul 12, 2020 at 01:09:18PM -, GitLab Bridge on behalf of 
> pbrobinson wrote:
> > From: pbrobinson on gitlab.com
> >
> > Revert the old version of the patches, apply the latest upstream
> > version:
>
> Hi Peter,
>
> It looks like most of your patches are git cherry-picks?  If so, just using
> 'git cherry-pick -x' records the commit sha from the submaintainers tree and
> satisfies Jiri's request.  Hopefully that is an easy tweak to make???

Not that I'm aware of, they were from patchwork, they were a newer
version of a patch set we had already pulled in that I retrieved from
the arm-kernel list patchwork, we often do that on Arm on Fedora
around enablement of popular devices.
___
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.7.X <=33

[Peter Robinson]

> I'm not seeing any kernel 5.7.1, 5.7.2 kernel builds in koji and on it's
> way to <=33 now after 5.7.1 had been released ( expected after 5.7.1,
> there are two weeks since last 5.7.x build ) is that part of this new
> workflow along with this significant CI noise and needless one line ack

Nothing at all related to it what so ever. The standard process for
new stable kernels in Fedora stable releases has been "sometime after
the .3 release" and has been that as long as I've been involved in
kernel stuff (about 10 years).

The process for stable lands the new kernel into the stabilization in
dist-git, and 5.7.2 has been there since Wed 10th, from there the
various maintainers check it's ready and then a test week is scheduled
and initial builds are done.

The process is unchanged by any of the changes for the rawhide kernel
building which has the new process. Justin is on PTO this week, later
this week upstream will no doubt do a 5.7.3 release and I suspect next
week there will be a test day.

> messages on what was otherwise a mailinglist in which people could have
> meaningful discussions ( as of today 41 messages of pure noise until you
> reach Justin Forbes "Re: Streamlining the ARK config process" )?

As one of the community kernel maintainers doing a bunch of the arm
related kernel stuff in my own time I am actually just fine with the
the messages, the increase in actively is larger than the very quiet
kernel list before but it's still completely manageable and with
headers etc the messages are very easily filtered if you don't like
them.

> Did not the RH management that conducted this takeover of the Fedora
> kernel process even consider creating a separated mailinglist (
> kernel-ci, kernel-build whatever ) when it started projecting it's
> internal spaghetti mess of process,workflows and cluttered pipelines
> onto the community?

Well as far as I'm aware "RH management" had nothing to do with the
change of process and it came directly from the actual kernel
maintainers both in Fedora and Red Hat. It will in the medium term
allow the wider community have a say and more of an impact as to what
RHEL kernels look like and opens up the process more, with my
community maintainer hat on (and I really have zero to do with the
internal RHEL kernel process) I actively welcome this.

Peter
___
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] [redhat] New configs in drivers/hwmon

[Peter Robinson]

On Fri, Jun 5, 2020 at 5:13 PM Thorsten Leemhuis  wrote:
>
> Hi Don!
>
> Am 05.06.20 um 17:01 schrieb Don Zickus:
> > Thanks for the feedback!
>
> Thx for saying that, I already feared I sooner or later might come
> across as the crazy guy that complains about everything and therefor not
> really taken seriously… ;-)
>
> > On Fri, Jun 05, 2020 at 02:24:13PM +0200, Thorsten Leemhuis wrote:
> >> Lo! I'm slightly puzzled. These messages are now sent to
> >> fedora-kernel-list, which kinda sounds like input from the fedora
> >> community is wanted. But all this discussions look RHEL-specific to me.
> > Yes.
> >
> >> Or am I missing something? Fedora at least seems to enable
> >> CONFIG_SENSORS_AMD_ENERGY if I read
> >> https://gitlab.com/cki-project/kernel-ark/-/blob/os-build/redhat/configs/fedora/generic/x86/CONFIG_SENSORS_AMD_ENERGY
> >>
> >> right. And that file is not touched by the patch. So from a perspective
> >> of someone Fedora developer that subscribes to fedora-kernel-list this
> >> and similar messages look like useless noise – and at the same time they
> >> are hard to read, as it's not easy to see if a patch is relevant for
> >> Fedora or not.
> > It is easy to see this as useless noise.
> > […]
> > I am open to suggestions to help create a better experience here.  Would
> > adding a keyword in the subject line help filter this?  Something else?
> > Maybe another mailing list for configs is something to bring back up?
>
> Well, I don't mind a few more mails, I already get a lot and they make
> not much of a difference, *if* they are useful somehow. But to be useful
> they are currently to hard to parse/understand: you have to scroll down
> quite far and at the same time look closely to not miss the interesting
> part, as that is only three lines long per symbol:
> ```
> +++ b/redhat/configs/common/generic/CONFIG_SENSORS_AMD_ENERGY
>
> @@ -0,0 +1 @@
>
> +# CONFIG_SENSORS_AMD_ENERGY is not set
> ```
>
> At the same time one IMHO relevant context information is missing
> afaics: how did the Fedora kernel maintainers set this option?
>
> IOW: I'd even like the mails if they would look more like this, where
> the interesting part is at the top:
>
> ```
> Subject: New configs in drivers/hwmon
>
> Set newly introduced config symbols like this in kernel-ark:
>
> * set CONFIG_SENSORS_AMD_ENERGY to 'not set' for RHEL ('m' in Fedora)
> * set CONFIG_SENSORS_MAX16601 to 'not set' for RHEL ('not set' in Fedora)
>
> 
>  standard header that starts with 'As a reminder, the ARK configuration
> flow involves', and obviously the diff itself/>
> ```
>
>
> Maybe even add the config symbol to the subject if it doesn't get to
> long that way.
>
> That would makes these mails a lot more useful and easier to review for
> me. And I guess it's the same for RH partners and customers as well.

Yes, I agree with that summary, it would make it more useful for me too.

> > Please keep the feedback
>
> Be careful what you wish for ;-)
>
> > coming, we will slowly work through this!
>
> Thx for working on this, much appreciated!
>
> CU, knurd
> ___
> 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: [OS-BUILD PATCH] configs/aarch64: Fix CONFIG_FORCE_MAX_ZONEORDER

[Peter Robinson]

> > > The internal make command 'make rh-brew'/'make dist-brew' is failing with
> > >
> > > Processing 
> > > /home/prarit/git-kernel/kernel-ark/redhat/configs/kernel-aarch64-debug-fedora.config
> > >  ... Error: Mismatches found in configuration files
> > > Found CONFIG_FORCE_MAX_ZONEORDER=11 after generation, had 
> > > CONFIG_FORCE_MAX_ZONEORDER=13 in Source tree
> > >
> > > ARK commit f5ca593e1c2e ("configs: Adjust CONFIG_FORCE_MAX_ZONEORDER for
> > > Fedora") set this to 11, and follow-on ARK commit dd028d261347 ("[redhat]
> > > Sync up ARK's Fedora config tree with Fedora's dist-git") erroneously
> > > overwrote the value back to 13.
> > >
> > > Set CONFIG_FORCE_MAX_ZONEORDER back to 11 for aarch64.
> >
> > For reference the reason we have this disparity goes back to why
> > Fedora doesn't have 64K page sizes for aarch64. The reason is because
> > with 64K pages it makes CMA 512Mb rather than the 64Mb (which I think
> > can actually be 16) we have with 4K pages. I seem to remember its
> > something to do with CMA using large pages and with 64K page sizes
> > that makes the smallest large page to be 512Mb.
> >
> > Losing 512Mb is obviously fatal on devices with small amounts of RAM
> > like a bunch of the SBCs we support on Fedora so to support SBCs we
> > had to move to 4K pages until we got a proper fix for this. Related it
> > actually also affects RHEL for things like AWS images with small
> > amounts of memory so I suspect it would be useful to be fixed in the
> > RHEL use case too.
>
> Thanks Peter for the context!
>
> Mark should we enable this for ARK / RHEL-9?

I suspect 64K page size with the default CONFIG_FORCE_MAX_ZONEORDER
for that is what we want for RHEL, which I would think is what it
currently is.

The fix for both, which would allow Fedora to go back to 64K page
sizes and be the same as elX, would be the fix to allow smaller CMA
allocations.
___
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] configs/aarch64: Fix CONFIG_FORCE_MAX_ZONEORDER

[Peter Robinson]

> From: Prarit Bhargava 
>
> The internal make command 'make rh-brew'/'make dist-brew' is failing with
>
> Processing 
> /home/prarit/git-kernel/kernel-ark/redhat/configs/kernel-aarch64-debug-fedora.config
>  ... Error: Mismatches found in configuration files
> Found CONFIG_FORCE_MAX_ZONEORDER=11 after generation, had 
> CONFIG_FORCE_MAX_ZONEORDER=13 in Source tree
>
> ARK commit f5ca593e1c2e ("configs: Adjust CONFIG_FORCE_MAX_ZONEORDER for
> Fedora") set this to 11, and follow-on ARK commit dd028d261347 ("[redhat]
> Sync up ARK's Fedora config tree with Fedora's dist-git") erroneously
> overwrote the value back to 13.
>
> Set CONFIG_FORCE_MAX_ZONEORDER back to 11 for aarch64.

For reference the reason we have this disparity goes back to why
Fedora doesn't have 64K page sizes for aarch64. The reason is because
with 64K pages it makes CMA 512Mb rather than the 64Mb (which I think
can actually be 16) we have with 4K pages. I seem to remember its
something to do with CMA using large pages and with 64K page sizes
that makes the smallest large page to be 512Mb.

Losing 512Mb is obviously fatal on devices with small amounts of RAM
like a bunch of the SBCs we support on Fedora so to support SBCs we
had to move to 4K pages until we got a proper fix for this. Related it
actually also affects RHEL for things like AWS images with small
amounts of memory so I suspect it would be useful to be fixed in the
RHEL use case too.

Peter

> Fixes: dd028d261347 ("[redhat] Sync up ARK's Fedora config tree with Fedora's 
> dist-git")
> Signed-off-by: Prarit Bhargava 
> Cc: ho...@redhat.com
> Cc: jcl...@redhat.com
> ---
>  .../fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER   | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git 
> a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER 
> b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER
> index b730690db048..8220d67904ea 100644
> --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER
> +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER
> @@ -1,4 +1,4 @@
>  # We technically want this to be 13 for Fedora with 4K pages but that's only
>  # an option with an out of tree patch. Keep this 11 for compatibility until
>  # we figure out what we want here
> -CONFIG_FORCE_MAX_ZONEORDER=13
> +CONFIG_FORCE_MAX_ZONEORDER=11
> --
> 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: Stability issue with jetson-tk1NIC with 5.3+

[Peter Robinson]

> > > FYI, I've experienced a stability issue with the jetson-tk1 NIC since
> > > kernel 5.3 and later.
> > > This is reported upstream at 
> > > https://bugzilla.kernel.org/show_bug.cgi?id=206217
> > > To sum-up: under some "MMC and network I/O load" (dnf update or scp of
> > > large file), the pciport receives AER errors that are actually fatal
> > > to  the network interface and cannot be recovered unless a reboot.
> > >
> > > I've bisected the issue and found the commit that once reverted,
> > > restore a good behaviour:
> > > https://patchwork.ozlabs.org/project/linux-tegra/patch/20200420164304.28810-1-kwiz...@gmail.com/
> > > I haven't experienced any other regression since then.
> > >
> > > What I would like to ask is:
> > > 1/ Is there any others reproducers for this issue on jetson-tk1 ?
> > > (issue only relevant on tegra124 SOC).
> > > 2/ As upstream agreed that a revert would be preferred until more
> > > investigation, can we consider to apply as a downstream patch until
> > > then ?
> >
> > I have on issues with the patch being applied.
> >
>
> I assume this is no issues?  I will pick it up with 5.6.14.

Correct
___
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: Stability issue with jetson-tk1NIC with 5.3+

[Peter Robinson]

> FYI, I've experienced a stability issue with the jetson-tk1 NIC since
> kernel 5.3 and later.
> This is reported upstream at 
> https://bugzilla.kernel.org/show_bug.cgi?id=206217
> To sum-up: under some "MMC and network I/O load" (dnf update or scp of
> large file), the pciport receives AER errors that are actually fatal
> to  the network interface and cannot be recovered unless a reboot.
>
> I've bisected the issue and found the commit that once reverted,
> restore a good behaviour:
> https://patchwork.ozlabs.org/project/linux-tegra/patch/20200420164304.28810-1-kwiz...@gmail.com/
> I haven't experienced any other regression since then.
>
> What I would like to ask is:
> 1/ Is there any others reproducers for this issue on jetson-tk1 ?
> (issue only relevant on tegra124 SOC).
> 2/ As upstream agreed that a revert would be preferred until more
> investigation, can we consider to apply as a downstream patch until
> then ?

I have on issues with the patch being applied.

Peter
___
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: RFC: Adding "Requires: alsa-sof-firmware" to F31 kernel-modules pkgs

[Peter Robinson]

On Wed, Apr 29, 2020 at 1:57 PM Justin Forbes  wrote:
>
> On Wed, Apr 29, 2020 at 7:49 AM Hans de Goede  wrote:
>
> > Hi,
> >
> > On 4/29/20 11:58 AM, Hans de Goede wrote:
> > > Hi All,
> > >
> > > As discussed before the new SOF audio driver needed for audio to
> > > function properly on recent Intel based laptops needs the
> > > alsa-sof-firmware package.
> > >
> > > For F32 this has been added to comps, but for F31 and for people
> > > upgrading from F31, we are still getting bug reports that audio
> > > does not work with newer kernels, see e.g. :
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1806334
> > >
> > > So we need to do something for F31 ASAP (and rely on people fully
> > > updating F31 before upgrading to fix upgrades to F32).
> > >
> > > My proposal still is to add a:
> > >
> > > Requires: alsa-sof-firmware
> > >
> > > To the F31 (and F30) kernel-modules sub-package.
> > >
> > > If I receive no objections to this I will add this change
> > > to distgit soon , so that it can be picked up by the next
> > > kernel build.
> > >
> > > Or even better if the maintainer of the current F30/F31
> > > kernel can do this before the next build, that would be
> > > great.
> >
> > And we just got the 3th bug report for this in 2 days:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1772498#c240
> >
> > Again after an upgrade to Fedora 32 (I guess people were
> > sticking with an older kernel on F31).
> >
> > I think we should consider also adding the Requires to
> > the F32 kernel-modules and rely on the comps thing for
> > F33 and later only.
> >
>
> I am not particularly happy with having to add it when the majority of
> systems do not actually require it, but I have seen the bugs and understand
> the position we are in. The alsa-sof-firmware package is 384k, I think
> adding it might be the best course of action.

Can we do a recommends rather than a hard requires please?
___
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: RFC: Adding "Requires: alsa-sof-firmware" to F31 kernel-modules pkgs

[Peter Robinson]

> As discussed before the new SOF audio driver needed for audio to
> function properly on recent Intel based laptops needs the
> alsa-sof-firmware package.
>
> For F32 this has been added to comps, but for F31 and for people
> upgrading from F31, we are still getting bug reports that audio
> does not work with newer kernels, see e.g. :
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1806334
>
> So we need to do something for F31 ASAP (and rely on people fully
> updating F31 before upgrading to fix upgrades to F32).

A distro-sync or system update should sync to the latest comps
additions so it should get pulled in as part of one of the supported
upgrade processes.

> My proposal still is to add a:
>
> Requires: alsa-sof-firmware
>
> To the F31 (and F30) kernel-modules sub-package.
>
> If I receive no objections to this I will add this change
> to distgit soon , so that it can be picked up by the next
> kernel build.
h>
> Or even better if the maintainer of the current F30/F31
> kernel can do this before the next build, that would be
> great.
>
> Regards,
>
> Hans
> ___
> 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: Fedora Rebase

[Peter Robinson]

On Mon, Apr 6, 2020 at 12:52 PM M. F. Ghani  wrote:
>
> If i understood correctly. On a high level, you mean that the currently 
> supported versions of fedora will be around less than a month behind the 
> mainline linux kernel right?

They will be rebased to the latest stable release around a month after
Linus tagged a new stable release. Rawhide is always up to date with
the latest mainline development.

> Best,
> - Ghani
>
>
> On Mon, Apr 6, 2020 at 1:46 AM Peter Robinson  wrote:
>>
>> > According to fedora docs, fedora kernels are rebased against the mainline
>> > linux kernel periodically. I wanted to know that is there a way to figure
>> > out the rebase date for particular commits. Just looking at the git log, it
>> > just gives the same date as the date in the mainline linux kernel git log.
>>
>> rawhide rebases to linus's HEAD constantly during the weekdays. Once
>> out of a merge window the RC that Linus usually does on a Sunday will
>> be a nodebug build in rawhide on Monday.
>>
>> A new stable, such as the just release 5.6 will usually start to land
>> into stable Fedora releases around the .3 release in the stable
>> release cycle, so I would expect the kernel team to start the process
>> to get 5.6 ready for F-31 in the next week or so.
>>
>> The "branched" release, in this case F-32, which is getting ready to
>> go stable is a little more nuanced and is generally dependent on where
>> the kernel/Fedora releases align, it's already on the 5.6.x series.
>>
>> Peter
___
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 Rebase

[Peter Robinson]

> According to fedora docs, fedora kernels are rebased against the mainline
> linux kernel periodically. I wanted to know that is there a way to figure
> out the rebase date for particular commits. Just looking at the git log, it
> just gives the same date as the date in the mainline linux kernel git log.

rawhide rebases to linus's HEAD constantly during the weekdays. Once
out of a merge window the RC that Linus usually does on a Sunday will
be a nodebug build in rawhide on Monday.

A new stable, such as the just release 5.6 will usually start to land
into stable Fedora releases around the .3 release in the stable
release cycle, so I would expect the kernel team to start the process
to get 5.6 ready for F-31 in the next week or so.

The "branched" release, in this case F-32, which is getting ready to
go stable is a little more nuanced and is generally dependent on where
the kernel/Fedora releases align, it's already on the 5.6.x series.

Peter
___
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?

[Peter Robinson]

> I see that exfat has landed in Linus' tree for 5.7 and is no longer in
> staging. Could backporting exfat from there into Fedora's 5.6 kernel
> tree be done so that we have exfat support in Fedora 32 at GA?

It landed upstream Friday and won't land into a Fedora kernel build
until Monday, and hence not a rawhide compose until Tuesday and he
which is the same day as we freeze F-32 so I personally don't think
it's worth the risk. Sure it's new functionality but I personally
think we're better off letting it bake in rawhide for a bit and let it
land into F-32 once it's rebased to 5.7 and it's had some time to
prove out a bit.
___
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: CONFIG_TCP_CONG_BBR not set on, in fc32 kernel confg

[Peter Robinson]

> I noticed that the kernel builds on the branched fedora32 kernels do not
> have CONFIG_TCP_CONG_BBR set ; meaning no shiny.

The kernel module is built:
$ modinfo tcp_bbr
filename:
/lib/modules/5.6.0-0.rc5.git0.2.fc32.x86_64/kernel/net/ipv4/tcp_bbr.ko.xz
description:TCP BBR (Bottleneck Bandwidth and RTT)

> root@kuriiti network-scripts]# sysctl
> net.ipv4.tcp_available_congestion_control
> net.ipv4.tcp_available_congestion_control = reno cubic

If you manually load the module it's there:

# sysctl -a | grep tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = reno cubic
# modprobe tcp_bbr
# sysctl -a | grep tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = reno cubic bbr

I'm not sure the "official" way to use different congestion control
algorithms but I'm guessing it's something you can use NetworkManager
to specify and autoload them.

Peter
___
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

[Peter Robinson]

On Fri, Mar 13, 2020 at 5:03 PM Javier Martinez Canillas
 wrote:
>
> Hello Jaroslav,
>
> On Tue, Mar 10, 2020 at 10:00 AM Jaroslav Kysela  wrote:
>
> [snip]
>
> >  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.
>
> I think we also need the requires in the kernel package for F32, since
> users could update their systems to F32 before it is released.

If they update using the recommended supported methods (upgrade and
dnf distro-sync) it will pull in new additions to the installed comps
groups so that should work fine with upgrades.
___
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

[Peter Robinson]

> > > > >> 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".
>
> Fedora's "trusted infrastructure" can't scale to what CKI is doing.
> One could argue about what trusted infrastructure means in general,
> because in my opinion there is no such thing, but it would be entirely
> irresponsible to overwhelm already limited capacity with something
> that is done at the scale CKI runs.  Figuring out how to get
> comfortable with using cloud resources for workloads where that make
> sense is critical to our long term success.

And git repos should be verifiable to the upstream so I believe this
should be no worse than any other git ecosystem.

> (FWIW, I'm trying really hard not to read your comment as a slam on
> the kernel team here.  I also find it an interesting example of
> cognitive dissonance that CKI running in AWS somehow triggers this
> comment, when all of Fedora is dependent on the mirror network to
> serve the actual binaries to users and *that* is far more risky than
> doing build testing in the cloud that doesn't even impact end-users.)

Package/repo signing mitigates that, but that can also be done in the
git side of things too.
___
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

[Peter Robinson]

On Tue, Mar 3, 2020 at 4:17 PM Hans de Goede  wrote:
>
> Hi,
>
> On 3/3/20 4:23 PM, Jeremy Cline wrote:
> > 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
>
> Right, that will work too and indeed is a better idea, at least for F30 + F31.
>
> The question is what do we want to do for F32+ ?
>
> 1. Add alsa-sof-firmware to comps, similar to how iwlwifi is handled

I vote for this one as it's consistent.

> 2. Use the same Recommends as we are doing for F30 + F31 ?
>
> I would personally prefer 2, but then we should probably consider
> doing the same for iwlwifi for consistency.
>
> Regards,
>
> Hans
>
___
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

[Peter Robinson]

> >>> 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.
>
> >> Also, SOF may be used on other architectures like i.MX ARM platforms. I can
> >> create packages with the different firmware files for specific 
> >> architectures
> >> instead one noarch package.
> >
> > I would split them up, I would probably still leave them as no-arch.
> >
> > I was going to ask for the arm NXP firmwares but I hadn't got as far
> > as investigating which SoCs they would be needed for.
>
> ATM the package is tiny, linux-firmware OTOH is not so tiny. Since we are

I'd not looked at the actual size, if it's small that's fine. Also if
it's just added to comps, like the various wireless firmware, it's
easy enough to exclude for usecases like cloud that won't need it.

> happily installing linux-firmware everywhere I do not think that splitting
> this up is worthwhile.

Well that's a completely different can of worms a lot don't
install it happily ;-)

> If we want to spend effort on splitting out firmware files in generic
> (used on multiple archs) and per arch firmware files then that effort
> is probably best spend on the linux-firmware packgae itself for starters.

If it's small leave it as one, it's easy enough to evolve later.
___
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

[Peter Robinson]

On Tue, Mar 3, 2020 at 12:27 PM Jaroslav Kysela  wrote:
>
> Dne 03. 03. 20 v 12:44 Hans de Goede napsal(a):
> > Hi,
> >
> > On 3/3/20 11:48 AM, Dan Horák wrote:
> >> On Tue, 3 Mar 2020 11:27:57 +0100
> >> Hans de Goede  wrote:
> >>
> >>> Hi,
> >>>
> >>> On 3/3/20 9:11 AM, Jaroslav Kysela wrote:
>  Dne 02. 03. 20 v 12:02 Hans de Goede napsal(a):
> > Hi Jaroslav,
> >
> > Thank you for starting a discussion about this, we really need
> > to get this sorted out soon-ish as a lot of users are reporting
> > broken audio with 5.5.x because of the missing SOF firmware.
> >
> > On 3/2/20 11:10 AM, Jaroslav Kysela wrote:
> >> Hi all,
> >>
> >>   I would like you to introduce the situation with the Intel's
> >> Sound Open Firmware. We have finally a stable version of the
> >> driver in the Fedora kernel (5.5.7), so it's time to discuss this.
> >>
> >>   The issue is that Intel need to deal with three type of
> >> files. The first file is the firmware (binary instruction blob
> >> which is executed in DSP, suffix .ri). The second file is the
> >> topology and configuration for the ALSA's ASoC core / SOF driver
> >> (suffix .tplg). Those both files are loaded via the firmware load
> >> calls from the kernel. The names for those files are determined
> >> using the hardware probe. The .ri files are platform (Broadwell
> >> etc.) dependent. The topology files might differ more (HDMI
> >> configuration, codec configuration etc.).
> >>
> >>   The third file is not loaded via the firmware call, it
> >> contains the debug strings (SOF firmware is stripped, thus only
> >> pointers are returned through the trace interface and there's
> >> utility sof-logger which converts those pointers back to the
> >> strings using those .ldc files). It's just for the debugging
> >> purposes and for the normal operation, it is not used at all.
> >>
> >>   The last piece is the signing. Intel has a secure mechanism
> >> which is activated in DSP, so DSP doesn't accept the unsigned
> >> firmware, if the hardware vendor wants (and they usually wants
> >> this security). So, although, the SOF firmware is being developed
> >> as open source, we cannot do own modifications, because we don't
> >> have the signing keys. Of course, there is open hardware where
> >> the public keys are used (like UP^2 or some Chromebooks). But
> >> Lenovo, Dell and others requires firmware signed by Intel.
> >>
> >>   Personally, I'm trying to convince Intel's people to release
> >> the stable signed firmware files to linux-firmware, but so far, I
> >> have not been successful so far. My opinion is that the tested
> >> and verified binary topology files should belong to the
> >> linux-firmware, too. Intel do not agree on this (distributions
> >> should compile the topology binaries from the sources).
> >> Unfortunately, the topology sources are not distributed
> >> separately from the SOF firmware, so we need to deal with the
> >> whole SOF tree.
> >>
> >>   For Fedora, I'm packaging the SOF firmware, topology and
> >> debug (.ldc) bundle
> >> (https://www.alsa-project.org/files/pub/misc/sof/) via the
> >> alsa-firmware package for now (this package is not installed by
> >> default which causes another bug iteration 'install this package'
> >> for users). Note that this is not in the upstream alsa-firmware
> >> tar ball. It's an extra thing.
> >>
> >>   The last activity from the Intel is the sof-bin repository:
> >> https://github.com/thesofproject/sof-bin/tree/stable-v1.4.2 .
> >> It's probably a good step forward to have this reference, but
> >> it's outside the linux-firmware repository. I don't know if they
> >> want to mirror this to linux-firmware.
> >>
> >>   The objective: Fedora/RHEL users should have sound available
> >> after the initial installation, thus we need to find the way to
> >> add those files to linux-firmware or install alsa-firmware
> >> package by default. Maybe, the best way will be to create another
> >> alsa-sof-bin package for the Intel's sof-bin releases and install
> >> it by default like iwl*-firmware files for their WiFi chips.
> >
> > Since the SOF firmware files have a separate upstream I think
> > that creating a separate alsa-sof-bin (*) package is probably
> > the best approach, at least for now since upstream does not
> > seem to be moving to adding the signed DSP firmware files to
> > linux-firmware anytime soon.
> >
> > As for where the topology files go, inside alsa-sof-firmware or
> > inside alsa-ucm, both need to be installed for things to work
> > anyways, so I will leave that up to you.
> 
>  The topology files are bundled in sof-bin, too. Intel does some CI
>  test

Re: Intel SOF firmware

[Peter Robinson]

> >> Thank you for starting a discussion about this, we really need
> >> to get this sorted out soon-ish as a lot of users are reporting
> >> broken audio with 5.5.x because of the missing SOF firmware.
> >>
> >> On 3/2/20 11:10 AM, Jaroslav Kysela wrote:
> >>> Hi all,
> >>>
> >>> I would like you to introduce the situation with the Intel's Sound 
> >>> Open Firmware. We have finally a stable version of the driver in the 
> >>> Fedora kernel (5.5.7), so it's time to discuss this.
> >>>
> >>> The issue is that Intel need to deal with three type of files. The 
> >>> first file is the firmware (binary instruction blob which is executed in 
> >>> DSP, suffix .ri). The second file is the topology and configuration for 
> >>> the ALSA's ASoC core / SOF driver (suffix .tplg). Those both files are 
> >>> loaded via the firmware load calls from the kernel. The names for those 
> >>> files are determined using the hardware probe. The .ri files are platform 
> >>> (Broadwell etc.) dependent. The topology files might differ more (HDMI 
> >>> configuration, codec configuration etc.).
> >>>
> >>> The third file is not loaded via the firmware call, it contains the 
> >>> debug strings (SOF firmware is stripped, thus only pointers are returned 
> >>> through the trace interface and there's utility sof-logger which converts 
> >>> those pointers back to the strings using those .ldc files). It's just for 
> >>> the debugging purposes and for the normal operation, it is not used at 
> >>> all.
> >>>
> >>> The last piece is the signing. Intel has a secure mechanism which is 
> >>> activated in DSP, so DSP doesn't accept the unsigned firmware, if the 
> >>> hardware vendor wants (and they usually wants this security). So, 
> >>> although, the SOF firmware is being developed as open source, we cannot 
> >>> do own modifications, because we don't have the signing keys. Of course, 
> >>> there is open hardware where the public keys are used (like UP^2 or some 
> >>> Chromebooks). But Lenovo, Dell and others requires firmware signed by 
> >>> Intel.
> >>>
> >>> Personally, I'm trying to convince Intel's people to release the 
> >>> stable signed firmware files to linux-firmware, but so far, I have not 
> >>> been successful so far. My opinion is that the tested and verified binary 
> >>> topology files should belong to the linux-firmware, too. Intel do not 
> >>> agree on this (distributions should compile the topology binaries from 
> >>> the sources). Unfortunately, the topology sources are not distributed 
> >>> separately from the SOF firmware, so we need to deal with the whole SOF 
> >>> tree.
> >>>
> >>> For Fedora, I'm packaging the SOF firmware, topology and debug (.ldc) 
> >>> bundle (https://www.alsa-project.org/files/pub/misc/sof/) via the 
> >>> alsa-firmware package for now (this package is not installed by default 
> >>> which causes another bug iteration 'install this package' for users). 
> >>> Note that this is not in the upstream alsa-firmware tar ball. It's an 
> >>> extra thing.
> >>>
> >>> The last activity from the Intel is the sof-bin repository: 
> >>> https://github.com/thesofproject/sof-bin/tree/stable-v1.4.2 . It's 
> >>> probably a good step forward to have this reference, but it's outside the 
> >>> linux-firmware repository. I don't know if they want to mirror this to 
> >>> linux-firmware.
> >>>
> >>> The objective: Fedora/RHEL users should have sound available after 
> >>> the initial installation, thus we need to find the way to add those files 
> >>> to linux-firmware or install alsa-firmware package by default. Maybe, the 
> >>> best way will be to create another alsa-sof-bin package for the Intel's 
> >>> sof-bin releases and install it by default like iwl*-firmware files for 
> >>> their WiFi chips.
> >>
> >> Since the SOF firmware files have a separate upstream I think
> >> that creating a separate alsa-sof-bin (*) package is probably
> >> the best approach, at least for now since upstream does not
> >> seem to be moving to adding the signed DSP firmware files to
> >> linux-firmware anytime soon.
> >>
> >> As for where the topology files go, inside alsa-sof-firmware or
> >> inside alsa-ucm, both need to be installed for things to work
> >> anyways, so I will leave that up to you.
> >
> > The topology files are bundled in sof-bin, too. Intel does some CI tests 
> > with them, so I'd prefer to keep them with the DSP firmware files.
> >
> >> If you can create such a package I would be happy to do the package
> >> review ASAP and then we can add a Requires for this to the kernel-core
> >> pkgs so that users will get it automatically when they install the
> >> next kernel update.

It should not be kernel-core, the sounds drivers are packaged in
kernel-modules, not -core, and it should probably be a soft requires
so it gets there by default but isn't enforces, and should also be
just for x86.

> > The review request: https://bugzilla.redhat.com/show_bug.cgi?id=1809303

Re: About new 5.6 CONFIG_EFI_DISABLE_PCI_DMA option

[Peter Robinson]

> I've been involved (a tiny bit) in the EFI stub cleanups which have
> landed for 5.6, a such I've been building my own test kernels with
> CONFIG_EFI_DISABLE_PCI_DMA=y up to know that is.
>
> Recently I got a Lenovo X1 + Thunderbolt 3 dock for testing and
> booting my own test kernel build on it failed, disabling
> CONFIG_EFI_DISABLE_PCI_DMA fixes this.
>
> Note currently we have:
>
> [hans@x1 master]$ cat configs/fedora/generic/CONFIG_EFI_DISABLE_PCI_DMA
> # CONFIG_EFI_DISABLE_PCI_DMA is not set
>
> So the Fedora 5.6 kernels should work and this is not a bug report,
> this is mostly a heads up and trying to turn my knowledge that for
> now turning this on is not a good idea form private knowledge into
> collective knowledge.
>
> I will also report this upstream, so that maybe this issue can be
> fixed.

The Kconfig text on this is pretty decent:

https://cateee.net/lkddb/web-lkddb/EFI_DISABLE_PCI_DMA.html

It also looks like it might be hard to enable by default on a generic
kernel, but from a security PoV it would certainly be something that
would be useful to be able to enable.
___
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: stepping down as fedora kernel maintainer

[Peter Robinson]

> After quite a bit of soul searching, I've decided to step down from
> being a full-time Fedora kernel maintainer and move on to other things.
> Having come in as a relative outsider to the Fedora community almost
> 5 years ago, I deeply appreciate you all welcoming me with open arms.
> I still expect to be around to some degree but probably not as
> directly involved on a day-to-day basis. I would also like to thank
> jcline, jforbes and jwboyer for being amazing supportive teammates
> during my tenure. Thank you everyone for being patient as I attempted
> to fix more bugs than I introduced in the kernel.

Laura, while I've expressed this privately, I would like to publicly
say thank you for all that you've done. I've thoroughly enjoyed
working with you over the years in the Fedora project and your
involved has stretched far wider to things like outreachy and other
related things. I will miss you, and I know many others will as well.
Thank you, and all the best for your future endevours. I look forward
to running into you at various conferences.

Peter
___
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: NO_HZ_IDLE on x86_64?

[Peter Robinson]

> >  Hey All.
> > 
> >  In digging through some pieces around CPU_IDLE I noticed that
> >  NO_HZ_IDLE is explicitly disabled on x86_64 but not on all other
> >  architectures.
> > 
> >  Doing a "git log --follow
> >  configs/fedora/generic/x86/x86_64/CONFIG_NO_HZ_IDLE" it goes all the
> >  way back to 2016 when we changed the way the configs were handled.
> > 
> >  The upstream kernel's opinion [1] on it is "Most of the time you want
> >  to say Y here." so I'm wondering if there's a reason why we're
> >  difference on x86_64 or is it just lost in the winds of time?
> > 
> >  Peter
> > 
> >  PS was digging around CPU_IDLE_GOV_TEO for those curious.
> > 
> >  [1] https://cateee.net/lkddb/web-lkddb/NO_HZ_IDLE.html
> > >>>
> > >>>
> > >>> commit 3836faf6e68495fc70316229a3540506f7ce4c98
> > >>> Author: Kyle McMartin 
> > >>> Date:   Wed Sep 17 13:10:12 2014 -0500
> > >>>
> > >>>  re-enable RCU_FAST_NO_HZ, enable NO_HZ_FULL on x86_64
> > >>>
> > >>>  - I also like to live dangerously. (Re-enable RCU_FAST_NO_HZ which
> > >>> has been off
> > >>>since April 2012. Also enable NO_HZ_FULL on x86_64.)
> > >>
> > >> Yeah I wouldn't quite say it's been "lost" but the real question
> > >> is if it still makes sense. I don't have a strong opinion without
> > >> data. Prarit, any opinion here?
> > >
> > > Oh, I wasn't pointing out that it wasn't just lost, I was pointing out
> > > that NO_HZ_IDLE is not set because we run NO_HZ_FULL. We were one of
> > > the first distros to do so, and it has worked well for us.  I have a
> > > fairly strong opinion about not dropping back to IDLE without good
> > > reason.
> >
> > Getting back to the original question, I had to go back through my history 
> > to
> > see if I could find a reason why there is a discrepancy between x86 and the
> > other arches.
> >
> > AFAICT in *RHEL8* we have NO_HZ_FULL on all arches except s390x.  S390x has
> > NO_HZ_IDLE.  Additionally s390 upstream has:
> >
> > [prarit@prarit linux]$ git grep NO_HZ_IDLE arch/s390/
> > arch/s390/configs/debug_defconfig:4:CONFIG_NO_HZ_IDLE=y
> > arch/s390/configs/defconfig:4:CONFIG_NO_HZ_IDLE=y
> > arch/s390/configs/zfcpdump_defconfig:2:CONFIG_NO_HZ_IDLE=y
> >
> > On Fedora, as noted,
> >
> > [prarit@prarit fedora]$ find ./ -name *NO_HZ_IDLE* | xargs grep ^
> > ./generic/x86/x86_64/CONFIG_NO_HZ_IDLE:# CONFIG_NO_HZ_IDLE is not set
> > ./generic/CONFIG_NO_HZ_IDLE:CONFIG_NO_HZ_IDLE=y
> > [prarit@prarit fedora]$ find ./ -name *NO_HZ_FULL* | xargs grep ^
> > ./generic/x86/x86_64/CONFIG_NO_HZ_FULL:CONFIG_NO_HZ_FULL=y
> > ./generic/CONFIG_NO_HZ_FULL:# CONFIG_NO_HZ_FULL is not set
> >
> > FWIW I think the correct thing to do for performance reasons is use 
> > NO_HZ_FULL
> > on all arches except s390x which requires NO_HZ_IDLE.
> >
> Yes, I do believe this is the correct thing to do, as to how we got
> into the current state, when NO_HZ_FULL was introduced, it was x86_64
> only. Other architectures came in eventually, but as they were already
> set to NO_HZ_IDLE, it didn't prompt us, and to be honest, we were
> paying less attention to the other architectures back then. It has
> been a while.  I will get the changes made in rawhide with tomorrow's
> builds.

It looks good on the arm architectures, thanks for everyone's feedback.

Peter
___
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: NO_HZ_IDLE on x86_64?

[Peter Robinson]

> > On 12/12/19 9:10 AM, Justin Forbes wrote:
> > > On Thu, Dec 12, 2019 at 3:48 AM Peter Robinson  
> > > wrote:
> > >>
> > >> Hey All.
> > >>
> > >> In digging through some pieces around CPU_IDLE I noticed that
> > >> NO_HZ_IDLE is explicitly disabled on x86_64 but not on all other
> > >> architectures.
> > >>
> > >> Doing a "git log --follow
> > >> configs/fedora/generic/x86/x86_64/CONFIG_NO_HZ_IDLE" it goes all the
> > >> way back to 2016 when we changed the way the configs were handled.
> > >>
> > >> The upstream kernel's opinion [1] on it is "Most of the time you want
> > >> to say Y here." so I'm wondering if there's a reason why we're
> > >> difference on x86_64 or is it just lost in the winds of time?
> > >>
> > >> Peter
> > >>
> > >> PS was digging around CPU_IDLE_GOV_TEO for those curious.
> > >>
> > >> [1] https://cateee.net/lkddb/web-lkddb/NO_HZ_IDLE.html
> > >
> > >
> > > commit 3836faf6e68495fc70316229a3540506f7ce4c98
> > > Author: Kyle McMartin 
> > > Date:   Wed Sep 17 13:10:12 2014 -0500
> > >
> > >  re-enable RCU_FAST_NO_HZ, enable NO_HZ_FULL on x86_64
> > >
> > >  - I also like to live dangerously. (Re-enable RCU_FAST_NO_HZ which
> > > has been off
> > >since April 2012. Also enable NO_HZ_FULL on x86_64.)
> >
> > Yeah I wouldn't quite say it's been "lost" but the real question
> > is if it still makes sense. I don't have a strong opinion without
> > data. Prarit, any opinion here?
>
> Oh, I wasn't pointing out that it wasn't just lost, I was pointing out
> that NO_HZ_IDLE is not set because we run NO_HZ_FULL. We were one of
> the first distros to do so, and it has worked well for us.  I have a
> fairly strong opinion about not dropping back to IDLE without good
> reason.

This wasn't a proposal to change anything here at all, sorry if that
was the way it read. I was purely wondering, while digging through
stuff around cpu idle, for the difference between arches.

With the hit around NO_HZ_IDLE vs NO_HZ_FULL I dug some more and
basically it seems the reason we don't have the later on the non
x86_64 arches is because for some reason we unset
VIRT_CPU_ACCOUNTING_GEN for all except x86_64, it looks to be
historical, all our current architectures now look to support that
option. Anyone aware of any reason we shouldn't use the
NO_HZ_FULL/VIRT_CPU_ACCOUNTING_GEN as standard across all arches?

P
___
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

NO_HZ_IDLE on x86_64?

[Peter Robinson]

Hey All.

In digging through some pieces around CPU_IDLE I noticed that
NO_HZ_IDLE is explicitly disabled on x86_64 but not on all other
architectures.

Doing a "git log --follow
configs/fedora/generic/x86/x86_64/CONFIG_NO_HZ_IDLE" it goes all the
way back to 2016 when we changed the way the configs were handled.

The upstream kernel's opinion [1] on it is "Most of the time you want
to say Y here." so I'm wondering if there's a reason why we're
difference on x86_64 or is it just lost in the winds of time?

Peter

PS was digging around CPU_IDLE_GOV_TEO for those curious.

[1] https://cateee.net/lkddb/web-lkddb/NO_HZ_IDLE.html
___
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: cleaning out some scripts from the kernel dist-git

[Peter Robinson]

On Fri, Nov 22, 2019 at 9:27 PM Laura Abbott  wrote:
>
> The kernel dist-git has a number of scripts in the script directory.
> Some are used for regular work (stable-update.sh, rawhide-rc.sh,
> rawhide-snapshot.sh) but some of them haven't been used in a
> long time. I'd like to delete the following:
>
> - check-patchlist.sh
> - check-TODO.sh
> - combine.sh
> - grab-logs.sh
> - newpatch.sh
>
> Does anyone have an issue with removing these scripts?

Fine by me, easy enough to resurrect from git if necessary.
___
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

[Peter Robinson]

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
___
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: New subpackages for Fedora

[Peter Robinson]

On Fri, Oct 25, 2019 at 7:26 PM Laura Abbott  wrote:
>
> Some of the downstream work I'm looking to bring back into Fedora is
> some new subpackages. Here's a brief explanation of what I'd like to
> bring in:
>
> - several packages with 'kabi' in the name. These are related to downstream
> ABI guarantees. All of the packages would be turned off for Fedora. No
> Fedora isn't getting any ABI guarantee.
>
> - ipaclones: this is related to kpatch support. This package will be turned
> off in Fedora. There are no plans to get kpatch support for Fedora at
> this time but like any feature if it makes sense to support it in the
> future we would consider it.
>
> - selftests: These are some bpf related selftests. This package will be
> turned off in Fedora.
>
> - modules-internal: Downstream wanted to designate a set of modules
> that get turned on but are not officially shipped. The existing
> design ends up building this package unconditionally so I was planning
> on bringing this in for Fedora. There are currently 4 modules that
> are designated for this package at the moment:
>
> mac80211_hwsim
> netdevsim
> pktgen
> rocker
>
> None of these seem like things that would be used in a regular Fedora
> system so I think it would be safe to move them around.
>
> I don't expect any of these changes to be particularly controversial
> but please let me know if you see any issue with this.
>
> I have a tree at 
> https://pagure.io/fedora-kernel-labbott/tree/align_fedora_oct25
> with everything I'd like to bring in. I've been testing and everything seems
> to work fine. If there are no objections, I plan to bring this in sometime
> next week.

Seems mostly sane to me, we can always evolve it as we go :-)
___
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

[Peter Robinson]

Why would you need intel drivers on Power?

On Wed, Oct 9, 2019 at 11:24 AM Dan Horák  wrote:
>
> This is for rawhide/5.4, they got disabled during the ARM config
> cleanups.
>
>
> Dan
>
> On Wed,  9 Oct 2019 12:21:34 +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
> > ___
> > 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
___
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: Simple Firmware Interface being deprecated

[Peter Robinson]

On Mon, Aug 26, 2019 at 9:27 PM Laura Abbott  wrote:
>
> https://lore.kernel.org/lkml/20190826181956.6918-1-lukas.bulw...@gmail.com/
>
> menuconfig SFI
>  bool "SFI (Simple Firmware Interface) Support"
>  ---help---
>  The Simple Firmware Interface (SFI) provides a lightweight method
>  for platform firmware to pass information to the operating system
>  via static tables in memory.  Kernel SFI support is required to
>  boot on SFI-only platforms.  Currently, all SFI-only platforms are
>  based on the 2nd generation Intel Atom processor platform,
>  code-named Moorestown.
>
>  For more information, see http://simplefirmware.org
>
>  Say 'Y' here to enable the kernel to boot on SFI-only platforms.
>
> I have no idea how common this is but Fedora does enable this option.
> If you are interested in salvaging this, please speak up!

Grepping config and the kernel it seems Moorestown is the Intel MID
platform and we explicitly disable X86_INTEL_MID so I'm not sure it's
a problem.

P
___
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/9] Clean up some old patches post F31

[Peter Robinson]

On Thu, 15 Aug 2019, 20:57 Laura Abbott,  wrote:

> I'd like to drop a bunch of patches Fedora has been carrying since
> forever. Most of these are fairly minor tweaks most people forgot
> we had and nobody cares about. My motivation is both in the spirit
> of cleaning up and also to better align Fedora + RHEL (I had a talk
> about this at Flock, video should be up soon).
>
> If someone wants to make an effort at upstreaming any of these, feel
> free to do so but I really think most of these are cruft.
>

I think all of these make sense, ultimately if they come up as an issue it
probably means there needs to be a discussion upstream to fix it properly
there.

It reminds me I've been meaning to do a similar review on some of the long
running but minor patches we have here for arm too.

Peter

Thanks,
> Laura
>
> Laura Abbott (9):
>   Drop namespaces config tweak
>   Drop cpumask auto select patch
>   Drop scsi warning patch
>   Remove ancient ath9k workaround
>   Drop old lis3 patch
>   Remove some old modalias adjustments
>   Remove old keyboard logging patch
>   Remove patch for GCC VTA
>   Remove crash driver
>
>  Kbuild-Add-an-option-to-enable-GCC-VTA.patch  |  94 ---
>  ath9k-rx-dma-stop-check.patch |  38 -
>  .../fedora/generic/x86/x86_64/CONFIG_NR_CPUS  |   2 +-
>  crash-driver.patch| 722 --
>  die-floppy-die.patch  |  29 -
>  input-kill-stupid-messages.patch  |  30 -
>  kernel.spec   |  20 -
>  ...-CPUMASK_OFFSTACK-usable-without-deb.patch |  34 -
>  lis3-improve-handling-of-null-rate.patch  |  75 --
>  namespaces-no-expert.patch|  27 -
>  no-pcspkr-modalias.patch  |  22 -
>  ...validate_disk-prevent-NULL-ptr-deref.patch |  39 -
>  12 files changed, 1 insertion(+), 1131 deletions(-)
>  delete mode 100644 Kbuild-Add-an-option-to-enable-GCC-VTA.patch
>  delete mode 100644 ath9k-rx-dma-stop-check.patch
>  delete mode 100644 crash-driver.patch
>  delete mode 100644 die-floppy-die.patch
>  delete mode 100644 input-kill-stupid-messages.patch
>  delete mode 100644
> lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
>  delete mode 100644 lis3-improve-handling-of-null-rate.patch
>  delete mode 100644 namespaces-no-expert.patch
>  delete mode 100644 no-pcspkr-modalias.patch
>  delete mode 100644 scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch
>
> --
> 2.21.0
> ___
> 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: [PATCH] Remove all Kconfig symbols dropped in v5.3-rc1

[Peter Robinson]

> Peter Robinson schreef op do 25-07-2019 om 09:08 [+0100]:
> > On Wed, Jul 24, 2019 at 9:46 PM Paul Bolle  wrote:
> > > Paul Bolle schreef op wo 24-07-2019 om 21:53 [+0200]:
> > > > There are 60 Kconfig symbols referenced in the files used for
> > > > configuration generation and in the shipped .config files that were
> > > > dropped in upstream v5.3-rc1. The references to these symbols can be
> > > > safely removed.
> > > >
> > No, I applied it.
>
> In a follow up to this patch up you disabled ISDN entirely. I'm perfectly fine
> with that.
>
> But shouldn't the packagers of the few ISDN related packages - like asterisk-
> misdn, isdn4k-utils, and mISDN - be notified that these packages might not
> work anymore (or might miss some functionality)?
>
> I'm not sure how the procedures involved work, so perhaps these packagers
> already know that ISDN is now disabled in master.

ISDN is mostly only useful now for telephony because all the data
networks have apparently been shut down, see the references to
upstream commits in my commit. I spoke with the asterisk maintainer
about the audio side of things.
___
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] Remove all Kconfig symbols dropped in v5.3-rc1

[Peter Robinson]

On Wed, Jul 24, 2019 at 9:46 PM Paul Bolle  wrote:
>
> Paul Bolle schreef op wo 24-07-2019 om 21:53 [+0200]:
> > There are 60 Kconfig symbols referenced in the files used for
> > configuration generation and in the shipped .config files that were
> > dropped in upstream v5.3-rc1. The references to these symbols can be
> > safely removed.
> >
> > These symbols are:
> > [...]
> > CONFIG_CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES
>
> A pedant - ie, someone like me - would suggest this typo would be dropped from
> this patch and be separately removed in some trivial patch. Do other people
> care enough and should I to redo this patch?

No, I applied it.

P

> Thanks,
>
> Paul Bolle
> ___
> 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: Bluetooth 2.0 devices regression fix

[Peter Robinson]

> > > Hey!
> > >
> > > Would it be possible to cherry-pick this patch:
> > > https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-mar...@holtmann.org/T/
> > > into Fedora 30 ASAP?
> >
> > It's already there and has been since we rebased to 5.1.x
> > https://src.fedoraproject.org/rpms/kernel/c/10868cd2f96f545744848175bad5bf88dda139a8?branch=f30
>
> My mistake. I checked rawhide, saw the patch wasn't applied, thought that the 
> f30 branch
> wouldn't have that patch either.

Should be in updates-testing for F-29 now too I believe.
___
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 2.0 devices regression fix

[Peter Robinson]

On Tue, Jun 4, 2019 at 1:22 PM Bastien Nocera  wrote:
>
> Hey!
>
> Would it be possible to cherry-pick this patch:
> https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-mar...@holtmann.org/T/
> into Fedora 30 ASAP?

It's already there and has been since we rebased to 5.1.x
https://src.fedoraproject.org/rpms/kernel/c/10868cd2f96f545744848175bad5bf88dda139a8?branch=f30

> A great number of input and audio devices are unusable because of
> the bug introduced in d5bb334a8e17 and we're seeing Bugzilla reports
> against bluez because of this.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1713896
> https://bugzilla.redhat.com/show_bug.cgi?id=1713980
> https://bugzilla.redhat.com/show_bug.cgi?id=1711654
>
> Cheers
> ___
> 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
___
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

[Peter Robinson]

ACK, the upstream of this became CONFIG_SUN50I_ERRATUM_UNKNOWN1

On Tue, Mar 19, 2019 at 9: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 
> ---
> Eyuball tested.
>
>  .../fedora/generic/arm/aarch64/CONFIG_SUN50I_A64_UNSTABLE_TIMER  | 1 -
>  kernel-aarch64-debug.config  | 1 -
>  kernel-aarch64.config| 1 -
>  3 files changed, 3 deletions(-)
>  delete mode 100644 
> configs/fedora/generic/arm/aarch64/CONFIG_SUN50I_A64_UNSTABLE_TIMER
>
> diff --git 
> a/configs/fedora/generic/arm/aarch64/CONFIG_SUN50I_A64_UNSTABLE_TIMER 
> b/configs/fedora/generic/arm/aarch64/CONFIG_SUN50I_A64_UNSTABLE_TIMER
> deleted file mode 100644
> index 1bf3b8e41a23..
> --- a/configs/fedora/generic/arm/aarch64/CONFIG_SUN50I_A64_UNSTABLE_TIMER
> +++ /dev/null
> @@ -1 +0,0 @@
> -CONFIG_SUN50I_A64_UNSTABLE_TIMER=y
> diff --git a/kernel-aarch64-debug.config b/kernel-aarch64-debug.config
> index 1746eae95cd7..a2b53c2d5d6b 100644
> --- a/kernel-aarch64-debug.config
> +++ b/kernel-aarch64-debug.config
> @@ -5986,7 +5986,6 @@ CONFIG_ST_UVIS25=m
>  CONFIG_ST_UVIS25_SPI=m
>  # CONFIG_SUN4I_EMAC is not set
>  CONFIG_SUN50I_A64_CCU=y
> -CONFIG_SUN50I_A64_UNSTABLE_TIMER=y
>  CONFIG_SUN50I_DE2_BUS=y
>  CONFIG_SUN50I_ERRATUM_UNKNOWN1=y
>  CONFIG_SUN50I_H6_CCU=y
> diff --git a/kernel-aarch64.config b/kernel-aarch64.config
> index 6c9684769048..904fa0df8fa8 100644
> --- a/kernel-aarch64.config
> +++ b/kernel-aarch64.config
> @@ -5964,7 +5964,6 @@ CONFIG_ST_UVIS25=m
>  CONFIG_ST_UVIS25_SPI=m
>  # CONFIG_SUN4I_EMAC is not set
>  CONFIG_SUN50I_A64_CCU=y
> -CONFIG_SUN50I_A64_UNSTABLE_TIMER=y
>  CONFIG_SUN50I_DE2_BUS=y
>  CONFIG_SUN50I_ERRATUM_UNKNOWN1=y
>  CONFIG_SUN50I_H6_CCU=y
> --
> 2.17.2
> ___
> 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
___
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

[Peter Robinson]

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  
> > >> 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.

P
___
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

[Peter Robinson]

On Sun, Mar 10, 2019 at 9:46 PM Christoph M.  wrote:
>
>
> On Sun, Mar 10, 2019 at 10:39 PM Peter Robinson  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
___
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

[Peter Robinson]

> 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?
___
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: surface pro 3 custom kernel

[Peter Robinson]

On Fri, Jan 18, 2019 at 1:05 PM Joao Cortes  wrote:
>
> Hi,
> I am following the instructions found in
> 1. https://docs.pagure.org/docs-fedora/building-custom-kernel.html
> 2. https://fedoraproject.org/wiki/Building_a_custom_kernel.
>
> I am trying to get fedora 29 support for microsoft surface pro 3 (including
> dock support).
> I am patching the 4.18.18-fc29 kernel, using the patches found in
>  https://github.com/jakeday/linux-surface, branch 4.18.20-4.
>
> This is what I have done,
> `
> git clone https://github.com/jakeday/linux-surface
> cd linux-surface
> git checkout 4.18.20-4
> cd ../
> fedpkg clone -a kernel
> cd kernel
> fedpkg switch-branch f29
> #going back to 4.18.18,
> git reset  --hard 87f9453dd6777020e4968779d61437a6f20b3614
> for i in ../linux-surface/patches/4.18/*; do ./scripts/newpatch.sh $i; done
> cp ../linux-surface/patches/4.18/* .
> `
>
> After running `fedpkg prep` (Is this a good way to test?),
> ``
> Applying: hid
> Applying: sdcard_reader
> Applying:
> fatal: empty ident name (for <>) not allowed
> error: Bad exit status from /var/tmp/rpm-tmp.ul7jtS (%prep)
> ``
> Removing two of jakeday's patches (0008-wifi.patch, 0009-surface3_power.patch)
> solves the issue.
> 1. This error indicates there is something wrong with the patch files? It 
> is issued by git

It indicates there's issues with the patches applying cleanly using
"git am" against the Fedora kernel.

> Running again `fedpkg prep`,
> `
> Found unset config items, please set them to an appropriate value
> CONFIG_INTEL_IPTS=n
> CONFIG_SURFACE_ACPI=n
> `
>
> I added both options to kernel-local file, but the error persists.
> It seems the file is not being used.
>2. Is it possible to debug the total list of config options, including
> those added in kernel-local?

Did you run ./build_configs.sh once you added them to regenerate the
configs? Once you've run that if you do a "git diff" you should see
the changes in the kernel-*.config files
___
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/3] Kconfig symbol cleanup for v5.0-rc1

[Peter Robinson]

On Fri, Jan 11, 2019 at 2:56 PM Paul Bolle  wrote:
>
> This short series cleans up all references to Kconfig symbols that have
> no effect on the build.
>
> This series is way too boring to review. But it can be tested by
> comparing the generated .config files (in the BUILD directory) before
> and after this series. These generated .config files should not change.
> Unless I made a mistake, that is.
>
> Anyhow, review and/or comments are, as always, appreciated. A build
> run on Fedora's build farm would be nice too. (I don't have access to
> that system.) But if I'm right that build should show no differences
> whatsoever.
>
> Paul Bolle (3):
>   Drop secure boot Kconfig symbols too
>   Remove all Kconfig symbols dropped in v5.0-rc1
>   Remove all references to unused Kconfig symbols
>
>  configs/fedora/debug/CONFIG_DEBUG_SLAB|   1 -
>  configs/fedora/generic/CONFIG_AB3100_CORE |   1 -
>  configs/fedora/generic/CONFIG_AB3100_OTP  |   1 -
>  configs/fedora/generic/CONFIG_AD5686  |   1 -
>  configs/fedora/generic/CONFIG_ADM8211 |   1 -
>  .../generic/CONFIG_AIC79XX_BUILD_FIRMWARE |   1 -
>  .../generic/CONFIG_AIC7XXX_BUILD_FIRMWARE |   1 -
>  configs/fedora/generic/CONFIG_AIRO|   1 -
>  configs/fedora/generic/CONFIG_AIRO_CS |   1 -
>  configs/fedora/generic/CONFIG_APM_POWER   |   1 -
>  configs/fedora/generic/CONFIG_AT76C50X_USB|   1 -
>  configs/fedora/generic/CONFIG_ATMEL   |   1 -
>  .../generic/CONFIG_ATM_AMBASSADOR_DEBUG   |   1 -
>  .../fedora/generic/CONFIG_ATM_FORE200E_DEBUG  |   1 -
>  .../generic/CONFIG_ATM_FORE200E_TX_RETRY  |   1 -
>  .../generic/CONFIG_ATM_FORE200E_USE_TASKLET   |   1 -
>  .../fedora/generic/CONFIG_ATM_HORIZON_DEBUG   |   1 -
>  configs/fedora/generic/CONFIG_ATM_IA_DEBUG|   1 -
>  .../fedora/generic/CONFIG_ATM_IDT77252_DEBUG  |   1 -
>  .../generic/CONFIG_ATM_IDT77252_RCV_ALL   |   1 -
>  configs/fedora/generic/CONFIG_ATM_ZATM_DEBUG  |   1 -
>  .../fedora/generic/CONFIG_BACKLIGHT_WM831X|   1 -
>  configs/fedora/generic/CONFIG_BCM63XX_PHY |   1 -
>  configs/fedora/generic/CONFIG_BCM7038_WDT |   1 -
>  configs/fedora/generic/CONFIG_BCM_FLEXRM_MBOX |   1 -
>  configs/fedora/generic/CONFIG_BLK_WBT_SQ  |   1 -
>  configs/fedora/generic/CONFIG_CAN_LEDS|   1 -
>  configs/fedora/generic/CONFIG_CAN_TSCAN1  |   1 -
>  configs/fedora/generic/CONFIG_CELL_CPU|   1 -
>  .../fedora/generic/CONFIG_CFQ_GROUP_IOSCHED   |   1 -
>  .../fedora/generic/CONFIG_CHARGER_PCF50633|   1 -
>  .../fedora/generic/CONFIG_CIFS_NFSD_EXPORT|   1 -
>  configs/fedora/generic/CONFIG_DEFAULT_CFQ |   1 -
>  .../fedora/generic/CONFIG_DEFAULT_DEADLINE|   1 -
>  configs/fedora/generic/CONFIG_DEFAULT_NOOP|   1 -
>  configs/fedora/generic/CONFIG_DEFXX   |   1 -
>  configs/fedora/generic/CONFIG_DPM_WATCHDOG|   1 -
>  .../generic/CONFIG_DVB_B2C2_FLEXCOP_DEBUG |   1 -
>  configs/fedora/generic/CONFIG_DVB_RTL2832_SDR |   1 -
>  .../generic/CONFIG_EFI_SIGNATURE_LIST_PARSER  |   1 -
>  configs/fedora/generic/CONFIG_ENC28J60|   1 -
>  configs/fedora/generic/CONFIG_EXOFS_DEBUG |   1 -
>  configs/fedora/generic/CONFIG_EZNPS_GIC   |   1 -
>  .../fedora/generic/CONFIG_FB_ATY128_BACKLIGHT |   1 -
>  .../fedora/generic/CONFIG_FB_ATY_BACKLIGHT|   1 -
>  configs/fedora/generic/CONFIG_FB_ATY_CT   |   1 -
>  configs/fedora/generic/CONFIG_FB_ATY_GX   |   1 -
>  configs/fedora/generic/CONFIG_FB_BROADSHEET   |   1 -
>  configs/fedora/generic/CONFIG_FB_HECUBA   |   1 -
>  .../fedora/generic/CONFIG_FB_NVIDIA_BACKLIGHT |   1 -
>  configs/fedora/generic/CONFIG_FB_NVIDIA_DEBUG |   1 -
>  configs/fedora/generic/CONFIG_FB_NVIDIA_I2C   |   1 -
>  .../generic/CONFIG_FB_PM2_FIFO_DISCONNECT |   1 -
>  configs/fedora/generic/CONFIG_FB_PRE_INIT_FB  |   1 -
>  .../fedora/generic/CONFIG_FB_RADEON_BACKLIGHT |   1 -
>  configs/fedora/generic/CONFIG_FB_RADEON_DEBUG |   1 -
>  configs/fedora/generic/CONFIG_FB_RADEON_I2C   |   1 -
>  .../fedora/generic/CONFIG_FB_RIVA_BACKLIGHT   |   1 -
>  configs/fedora/generic/CONFIG_FB_RIVA_DEBUG   |   1 -
>  configs/fedora/generic/CONFIG_FB_RIVA_I2C |   1 -
>  .../CONFIG_FW_LOADER_USER_HELPER_FALLBACK |   1 -
>  .../CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL|   1 -
>  .../CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE  |   1 -
>  .../fedora/generic/CONFIG_GPIO_104_DIO_48E|   1 -
>  .../fedora/generic/CONFIG_GPIO_104_IDIO_16|   1 -
>  configs/fedora/generic/CONFIG_GPIO_BT8XX  |   1 -
>  configs/fedora/generic/CONFIG_GPIO_TS5500 |   1 -
>  configs/fedora/generic/CONFIG_HSU_DMA_PCI |   1 -
>  .../generic/CONFIG_IMA_APPRAISE_BOOTPARAM |   1 -
>  .../generic/CONFIG_IMA_BLACKLIST_KEYRING  |   1 -
>  configs/fedora/generic/CONFIG_IMA_LOAD_X509   |   1 -
>  .../fedora/generic/CONFIG_IMA_TRUSTED_KEYRING |   1 -
>  .../fedora/generic/CONFIG_INPUT_PCF50633_PMU  |   1 -
>  .../generic/CONFIG_INPUT_RETU_PWRBUT

Re: ext4 file system corruption -> https://bugzilla.kernel.org/show_bug.cgi?id=201685

[Peter Robinson]

On Sun, Dec 2, 2018 at 5:04 PM Sérgio Basto  wrote:
>
> yeah yestarday my computer don't boot with kernel-4.18.20 , back to  
> kernel-core-4.18.19-100.fc27.x86_64.
>
> Thanks for the tip
>
> It might be related with [1] ?
> "I see that a 4.18.20-100.fc27 is already in koji, and unfortunately 4.18.xx 
> is now EOL.
> May I suggest that f27 to get a new 4.18.20 build with the STIBP backport 
> reverted
> please?  (Current 4.19.3-rc reverts that already.)"

Fedora 27 is end of life, the fix to this problem is to upgrade to a
newer release, or alternatively until you can upgrade you could run a
newer Fedora 28 kernel on Fedora 27.

Peter
___
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 typo 'CONFIG_SND_SOC_MSM8916_WCD_ANALOg'

[Peter Robinson]

On Tue, Nov 6, 2018 at 3:19 PM Justin Forbes  wrote:
>
> On Tue, Nov 6, 2018 at 6:45 AM, Paul Bolle  wrote:
> > It's clear that 'z' is a typo. Its net
> > effect is that armv7hl has been built with
> > # CONFIG_SND_SOC_MSM8916_WCD_ANALOG is not set
> >
> > for over a year now. Let's fix this and see if anyone notices.
> >
>
> Actually, if it has been off for a year, and no one has noticed and
> complained, it seems reasonable that no one is missing it. I will turn
> it off.

msm8916 is snapdragon 410 which is a 64 bit part, so while possibly
the IP was re-used in another QCom part i think it's safe to disable
for ARMv7
___
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] Sign the aarch64 kernel

[Peter Robinson]

On Tue, Oct 23, 2018 at 11:56 PM Jeremy Linton  wrote:
>
> The aarch64 kernel is a gzip'ed EFI image, this means
> that pesign needs to sign the original image and then
> zip it for grub to be able to validate the kernel image.

So ATM we don't have the actual HW which contains the signing keys
available on aarch64 so to sign with the kernels so we can't do this
just yet. I will open an infrastructure ticker so we can start to move
this forward though.

> Signed-off-by: Jeremy Linton 
> ---
>  kernel.spec | 19 ---
>  1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/kernel.spec b/kernel.spec
> index 25e4676a..e6601758 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -10,7 +10,7 @@ Summary: The Linux kernel
>
>  # Sign modules on x86.  Make sure the config files match this setting if more
>  # architectures are added.
> -%ifarch %{ix86} x86_64
> +%ifarch %{ix86} x86_64 aarch64
>  %global signkernel 1
>  %global signmodules 1
>  %global zipmodules 1
> @@ -1288,13 +1288,26 @@ BuildKernel() {
>cp arch/$Arch/boot/zImage.stub 
> $RPM_BUILD_ROOT/lib/modules/$KernelVer/zImage.stub-$KernelVer || :
>  fi
>  %if %{signkernel}
> +# aarch64 kernels are gziped EFI images
> +KernelExtension=${KernelImage##*.}
> +if [ "$KernelExtension" == "gz" ]; then
> +   SignImage=${KernelImage%.*}
> +else
> +   SignImage=$KernelImage
> +fi
> +
>  # Sign the image if we're using EFI
> -%pesign -s -i $KernelImage -o vmlinuz.signed
> +%pesign -s -i $SignImage -o vmlinuz.signed
>  if [ ! -s vmlinuz.signed ]; then
>  echo "pesigning failed"
>  exit 1
>  fi
> -mv vmlinuz.signed $KernelImage
> +mv vmlinuz.signed $SignImage
> +
> +if [ "$KernelExtension" == "gz" ]; then
> +   gzip -f9 $SignImage

Why gzip? Could this be xz?

> +fi
> +
>  %endif
>  $CopyKernel $KernelImage \
>  $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
> --
> 2.19.1
> ___
> 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
___
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: F28 kernels should not have CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER set

[Peter Robinson]

On Tue, Oct 9, 2018 at 2:34 PM Hans de Goede  wrote:
>
> Hi,
>
> I just noticed: https://bugzilla.redhat.com/show_bug.cgi?id=1637547
> getting filed. I'm suspicious that this may be caused by the new
> deferred fbcon takeover stuff.
>
> So I double checked the settings in the fedpkg f28 branch and I noticed
> that CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER is still set there,
> which was not the intention (FWIW I did add a note about this to
> rebase-notes.txt).
>
> Rather then dropping it myself I'm sending this mail so that you
> (Fedora kernel team) are aware of this in case similar bugs come in.
>
> I'll leave it up to you to disable this I do think it is best to
> disable this for F28.

If we should have this in F-29 GA we'll need a BZ for it so it can go
through the FE/Blocker process now.

P
___
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: Make kernel.spec friendlier to el7

[Peter Robinson]

On Wed, Oct 3, 2018 at 8:12 PM Pablo Sebastián Greco
 wrote:
>
> Didn't know about the "No attachment" rule, sorry.

The general rule is use "git send-email" and have them inline.

> disable_headers_fedora_only.patch:
> https://paste.fedoraproject.org/paste/QGmWcBvPRg3p8HnAcuNNPQ/
> make_buildflags_optional.patch:
> https://paste.fedoraproject.org/paste/VWDLrz7LSRSP5k9xQZKOpg/
>
> Pablo.
>
> El 3/10/18 a las 15:49, Pablo Sebastián Greco escribió:
> > We rebuild the Fedora kernel for CentOS with only a few changes
> > (mainly for armhfp).
> > Some of those changes may be part of Fedora, since they don't affect
> > the build process.
> >
> > disable_headers_fedora_only.patch: Fedora builds kernel-headers
> > separately, do this only for fedora.
> > make_buildflags_optional.patch: build_cflags and build_ldflags are not
> > available in el7, make them optional.
> >
> > Thanks.
> > Pablo
> >
> > ___
> > 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
> ___
> 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
___
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: Disabling kernel's hibernate support by default, allow re-enabling it with a kernel cmdline option

[Peter Robinson]

On Mon, Oct 1, 2018 at 3:42 PM Lennart Poettering  wrote:
>
> On Mo, 01.10.18 09:14, Justin Forbes (jmfor...@linuxtx.org) wrote:
>
> > > Lennart made a really interesting observation here, systemd
> > > is just proxying if "cat /sys/power/disk" indicates that
> > > hibernate is supported.
> > >
> >
> > No,  that is not what systemd is doing. The kernel provides a
> > mechanism, it does absolutely nothing with that mechanism unless told
> > to do so. What systemd is actually doing is creating a policy around
> > that mechanism.
>
> Well, we do provide a way to disallow hibernation in systemd, that's
> not the point.
>
> The thing though is: the hibernation subsystem in the Fedora kernel is
> in a relatively unique situation: it's enabled and installed on all
> installations by default, and adds a substantial, relatively invasive,
> non-trivial subsystem to the kernel — all while (as I understand) the
> Fedora kernel maintainers are not really willing to maintain it with
> the greatest love, and show no interest in turning this into a
> universally supported mechanism. Is there any other subsystem that is
> equally invasive which is enabled on all systems but where the
> maintainers are equally conservative in their will to support/fix it?
> I don't think so...

I also don't think your statement above is fair or correct. Firstly
the kernel is large, and the combination of hardware is vast and the
kernel team comprises ~3 people. So it's not that they don't maintain,
fix, engage with upstream to deal with problems it's just that is
limited with the resources available, especially when the bug reports
can be as vast as "feature X stopped working" without details of the
hardware or anything useful. I've seen numerous occasions when
something has regressed and there's useful report various hibernate
related issues be fixed, it's just hard with the limited resources,
both people's time and actual HW to test on, to be able to be sure the
functionality is good in all usecases.

> To compare this with other cases: usually code that the package
> maintainers don't want to maintain with the highest priority and
> greatest love is split into separate RPMs, and not installed by
> default. But in this case that's not really possible...

Yes, that might be the case for some distros, for enterprise distros
the functionality might even be provided via a different repository
that you need to explicitly have to enable. Unfortunately for a
hibernation it's not really a feature that can be split into a kernel
sub package called
kernel-hibernation-if-you-install-it-and-it-breaks-you-keep-both-pieces
with the appropriate blinking lights.

> Also, while of course I personally think that people should use
> systemd's APIs to hibernate the system this is not really how the
> world works. There are plenty of howtos on the internet that suggest
> people to use the /sys interface directly to hibrenate the system from
> their scripts. And hence that's how people often do it. Turning off
> hibrenation in levels high up in the stack hence kinda is less than
> ideal, as all those scripts don't care a tiny bit about that if they
> use the API advertised by the kernel itself...
>
> > While this change would "solve" the problem, I do not believe it is
> > the correct place to do so. As mentioned above, the mechanism is not
> > flawed.  Some hardware does not support the mechanism, and has no way
> > of reporting as such, which is why policy has always been leave it off
> > unless the user knowingly triggers it.   Now we have changed the
> > policy, in a way that seems pretty much universally undesirable, the
> > solution is the revert the policy, not cripple the mechanism.
>
> I think it would be wise to generally only enable and advertise
> features in the Fedora kernel that the kernel maintainers are actually
> willing to support. To me it appears this is generally followed in all
> cases, but in this case the kernel advertises that hibernation is
> available, even though it is known to be broken in plenty cases with
> noone actually caring about it.
>
> Also: I am sure there's a lot of disagreement of what the
> responsibility of systemd is and what not, but I personally don't
> think it's our job to decide whether a specific kernel subsystem is
> high quality enough to override the kernel's own advertisement of it,
> or even to judge whether the Fedora kernel team's willingness to
> maintain said subsystem is big enough or not. I'd much rather if the
> kernel team would decide on their own, and advertise on their own what
> they think is good enough and supportable enough to be used by
> everybody.
>
> Or to say this differently: own the thing or turn it off.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> desktop mailing list -- desk...@lists.fedoraproject.org
> To unsubscribe send an email to desktop-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of

Re: [PATCH] Disable PXA/MMP arches - break suspend

[Peter Robinson]

On Tue, Aug 21, 2018 at 3:38 PM, Nicolas Chauvet  wrote:
> Theses arches select pxa_gpio which registers on unrelated hardwares.
> This prevent theses devices to enter suspend.
> (reproduced on trimslice)
>
> Disable theses arches until a proper fix is made upstream
> See rhbz#1619699

NACK, disabling a bunch of devices that others are probably using
because your device doesn't suspend is not an appropriate fix to the
problem.


> Signed-off-by: Nicolas Chauvet 
> ---
>  .../fedora/generic/CONFIG_VIDEO_MMP_CAMERA|  1 -
>  configs/fedora/generic/arm/CONFIG_GPIO_PXA|  1 +
>  configs/fedora/generic/arm/CONFIG_I2C_PXA |  2 +-
>  .../fedora/generic/arm/CONFIG_MMC_SDHCI_PXAV3 |  2 +-
>  .../fedora/generic/arm/CONFIG_MTD_NAND_PXA3xx |  2 +-
>  configs/fedora/generic/arm/CONFIG_PLAT_PXA|  1 +
>  .../generic/arm/armv7/armv7/CONFIG_ARCH_MMP   |  1 -
>  .../arm/armv7/armv7/CONFIG_KEYBOARD_PXA27x|  2 +-
>  .../arm/armv7/armv7/CONFIG_MACH_MMP2_DT   |  1 -
>  .../arm/armv7/armv7/CONFIG_MMC_SDHCI_PXAV2|  2 +-
>  .../generic/arm/armv7/armv7/CONFIG_MMP_PDMA   |  1 -
>  .../generic/arm/armv7/armv7/CONFIG_MMP_TDMA   |  1 -
>  .../generic/arm/armv7/armv7/CONFIG_PXA_DMA|  2 +-
>  .../generic/arm/armv7/armv7/CONFIG_SERIAL_PXA |  2 +-
>  .../arm/armv7/armv7/CONFIG_SERIAL_PXA_CONSOLE |  2 +-
>  .../arm/armv7/armv7/CONFIG_SND_MMP_SOC|  1 -
>  .../arm/armv7/armv7/CONFIG_SND_PXA910_SOC |  2 +-
>  kernel-aarch64-debug.config   |  9 ---
>  kernel-aarch64.config |  9 ---
>  kernel-armv7hl-debug.config   | 27 +--
>  kernel-armv7hl-lpae-debug.config  |  9 ---
>  kernel-armv7hl-lpae.config|  9 ---
>  kernel-armv7hl.config | 27 +--
>  kernel-i686-PAE.config|  1 -
>  kernel-i686-PAEdebug.config   |  1 -
>  kernel-i686-debug.config  |  1 -
>  kernel-i686.config|  1 -
>  kernel-ppc64le-debug.config   |  1 -
>  kernel-ppc64le.config |  1 -
>  kernel-s390x-debug.config |  1 -
>  kernel-s390x.config   |  1 -
>  kernel-x86_64-debug.config|  1 -
>  kernel-x86_64.config  |  1 -
>  33 files changed, 55 insertions(+), 71 deletions(-)
>  delete mode 100644 configs/fedora/generic/CONFIG_VIDEO_MMP_CAMERA
>  create mode 100644 configs/fedora/generic/arm/CONFIG_GPIO_PXA
>  create mode 100644 configs/fedora/generic/arm/CONFIG_PLAT_PXA
>  delete mode 100644 configs/fedora/generic/arm/armv7/armv7/CONFIG_ARCH_MMP
>  delete mode 100644 configs/fedora/generic/arm/armv7/armv7/CONFIG_MACH_MMP2_DT
>  delete mode 100644 configs/fedora/generic/arm/armv7/armv7/CONFIG_MMP_PDMA
>  delete mode 100644 configs/fedora/generic/arm/armv7/armv7/CONFIG_MMP_TDMA
>  delete mode 100644 configs/fedora/generic/arm/armv7/armv7/CONFIG_SND_MMP_SOC
>
> diff --git a/configs/fedora/generic/CONFIG_VIDEO_MMP_CAMERA 
> b/configs/fedora/generic/CONFIG_VIDEO_MMP_CAMERA
> deleted file mode 100644
> index 29d87e4f3..0
> --- a/configs/fedora/generic/CONFIG_VIDEO_MMP_CAMERA
> +++ /dev/null
> @@ -1 +0,0 @@
> -# CONFIG_VIDEO_MMP_CAMERA is not set
> diff --git a/configs/fedora/generic/arm/CONFIG_GPIO_PXA 
> b/configs/fedora/generic/arm/CONFIG_GPIO_PXA
> new file mode 100644
> index 0..6eb2a00e0
> --- /dev/null
> +++ b/configs/fedora/generic/arm/CONFIG_GPIO_PXA
> @@ -0,0 +1 @@
> +# CONFIG_GPIO_PXA is not set
> diff --git a/configs/fedora/generic/arm/CONFIG_I2C_PXA 
> b/configs/fedora/generic/arm/CONFIG_I2C_PXA
> index 59d18f0cb..f2f8c5056 100644
> --- a/configs/fedora/generic/arm/CONFIG_I2C_PXA
> +++ b/configs/fedora/generic/arm/CONFIG_I2C_PXA
> @@ -1 +1 @@
> -CONFIG_I2C_PXA=m
> +# CONFIG_I2C_PXA is not set
> diff --git a/configs/fedora/generic/arm/CONFIG_MMC_SDHCI_PXAV3 
> b/configs/fedora/generic/arm/CONFIG_MMC_SDHCI_PXAV3
> index f6e6fdd55..c6361724e 100644
> --- a/configs/fedora/generic/arm/CONFIG_MMC_SDHCI_PXAV3
> +++ b/configs/fedora/generic/arm/CONFIG_MMC_SDHCI_PXAV3
> @@ -1 +1 @@
> -CONFIG_MMC_SDHCI_PXAV3=m
> +# CONFIG_MMC_SDHCI_PXAV3 is not set
> diff --git a/configs/fedora/generic/arm/CONFIG_MTD_NAND_PXA3xx 
> b/configs/fedora/generic/arm/CONFIG_MTD_NAND_PXA3xx
> index 584b57ea1..b004f397a 100644
> --- a/configs/fedora/generic/arm/CONFIG_MTD_NAND_PXA3xx
> +++ b/configs/fedora/generic/arm/CONFIG_MTD_NAND_PXA3xx
> @@ -1 +1 @@
> -CONFIG_MTD_NAND_PXA3xx=m
> +# CONFIG_MTD_NAND_PXA3xx is not set
> diff --git a/configs/fedora/generic/arm/CONFIG_PLAT_PXA 
> b/configs/fedora/generic/arm/CONFIG_PLAT_PXA
> new file mode 100644
> index 0..376e63960
> --- /dev/null
> +++ b/configs/fedora/generic/arm/CONFIG_PLAT_PXA
> @@ -0,0 +1 @@
> +# CONFIG_PLAT_PXA is not set
> diff --git a/configs/fedora/generic/arm/armv7/armv7/CONFIG_ARCH_MMP 
> b/configs/fedora/generic/arm/armv7

Re: Kernel lockdown patch & IPAddressAllow/IPAddressDeny systemd feature with Secure Boot

[Peter Robinson]

Probably a good idea to cc: this to the kernel list :-)

I suspect it's intentional but with the planned changes for iptables
etc to be backed by bpf in the upstream kernel sometime in the future
it's likely going to need to be reviewed.

Peter

On Tue, Aug 7, 2018 at 10:25 PM, Timothée Ravier  wrote:
> Booting Fedora with Secure Boot enabled will result in Lockdown being enabled 
> at boot time. This will completly disable the BPF system call for all users 
> [1][2].
>
> Unfortunately, this breaks the IPAddressAllow & IPAddressDeny systemd feature 
> [3][4][5].
>
> I don't have a solution for this, but as far as I understand, this will also 
> prevent other BPF use-cases (for example: Cilium on Fedora CoreOS).
>
> [1] 
> https://src.fedoraproject.org/rpms/kernel/blob/master/f/efi-lockdown.patch#_1525
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/jforbes/linux.git/commit/?h=lockdown&id=0eb0d0851747787f7182b3e9d0d38edb5925a678
> [3] https://github.com/systemd/systemd/blob/master/src/core/bpf-firewall.c
> [4] https://github.com/systemd/systemd/blob/master/NEWS#L1192
> [5] 
> https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#IPAddressAllow=ADDRESS%5B/PREFIXLENGTH%5D%E2%80%A6
> ___
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to devel-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/de...@lists.fedoraproject.org/message/ZMEWJMQH6DDMV3AZ4IG7LOYMMIETCH42/
___
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/message/RUWDEDQHS5I47YBPEZVEKXNU2BAX2SLU/

Re: PATCH: Enable-Apollo-Lake-Whiskey-Cove-PMIC-support.patch

[Peter Robinson]

On Mon, Jul 30, 2018 at 10:01 AM, Hans de Goede  wrote:
> Hi,
>
> If there are no objections I plan to push the attached patch to the
> rawhide kernel in the next couple of days.
>
> Note that we had e.g. the PMIC opregions for this already enabled
> in the past, see: configs/fedora/generic/x86/CONFIG_BXT_WC_PMIC_OPREGION
> which this patch does not change, but newer kernels have added more
> fine grained Kconfig options for the PMC_IPC bus between the
> Apollo Lake SoC and the PMIC, we ended up picking 'N' for the
> CONFIG_INTEL_PMC_IPC option, effectively disabling the PMIC support.

I don't see the patch
___
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/message/O3D34A5CAIBQUQIRQODARDSLBX4OMEEI/

SPECK crypto cipher

[Peter Robinson]

Thought I'd ask this one on list for reference.

So in 4.17 upstream added the SPECK cipher [1] but for reference the
ISO has rejected it (and SIMON) due to being designed by the NSA [2],
not sure it specifically matters for Fedora but I thought I'd put the
question out there if there's any thoughts or opinions on it.

I believe from a Linux perspective it's currently primarily used on
low end android phones that don't have HW crypto offload so it might
not even be widely used in Fedora.

Peter

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da7a0ab5b4babbe5d7a46f852582be06a00a28f0
[2] https://www.schneier.com/blog/archives/2018/04/two_nsa_algorit.html
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] kernel-tools.spec: Adding bpftool package

[Peter Robinson]

On Fri, 23 Mar 2018, 23:46 Jiri Olsa,  wrote:

> hi,
> please consider attached change that adds bpftool sub
> package to be generated within kernel-tools spec.
>
> The reason to have bpftool in separate rpm is to
> have minimal dependency for sosreport that will
> depend on it.
>
> The bpftool rpm contains following files:
>   $ rpm -ql -p bpftool-4.16.0-0.rc5.git0.1.fc29.x86_64.rpm
>   /etc/bash_completion.d/bpftool
>   /usr/sbin/bpftool
>   /usr/share/man/man8/bpftool-cgroup.8.gz
>   /usr/share/man/man8/bpftool-map.8.gz
>   /usr/share/man/man8/bpftool-prog.8.gz
>   /usr/share/man/man8/bpftool.8.gz
>
> thanks,
> jirka
>
>
> ---
>  kernel-tools.spec | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/kernel-tools.spec b/kernel-tools.spec
> index c8cbcff104fd..2d190d0497b6 100644
> --- a/kernel-tools.spec
> +++ b/kernel-tools.spec
> @@ -69,7 +69,7 @@ BuildRequires: kmod, patch, bash, tar, git
>  BuildRequires: bzip2, xz, findutils, gzip, m4, perl-interpreter,
> perl(Carp), perl-devel, perl-generators, make, diffutils, gawk
>  BuildRequires: gcc, binutils, redhat-rpm-config, hmaccalc
>  BuildRequires: net-tools, hostname, bc, elfutils-devel
> -BuildRequires: zlib-devel binutils-devel newt-devel python2-devel
> perl(ExtUtils::Embed) bison flex xz-devel
> +BuildRequires: zlib-devel binutils-devel newt-devel python2-devel
> python2-docutils perl(ExtUtils::Embed) bison flex xz-devel
>  BuildRequires: audit-libs-devel glibc-devel glibc-static
>  %ifnarch s390x %{arm}
>  BuildRequires: numactl-devel
> @@ -164,6 +164,13 @@ Provides: kernel-tools-devel
>  This package contains the development files for the tools/ directory from
>  the kernel source.
>
> +%package -n bpftool
> +Summary: Inspection and simple manipulation of eBPF programs and maps
> +License: GPLv2
> +%description -n bpftool
> +This package contains the bpftool, which allows inspection and simple
> +manipulation of eBPF programs and maps.
> +
>  %prep
>  %setup -q -n kernel-%{kversion}%{?dist} -c
>
> @@ -233,6 +240,9 @@ popd
>  pushd tools/gpio/
>  make
>  popd
> +pushd tools/bpf/bpftool
> +make
> +popd
>
>  ###
>  ### install
> @@ -299,6 +309,9 @@ popd
>  pushd tools/kvm/kvm_stat
>  make INSTALL_ROOT=%{buildroot} install-tools
>  popd
> +pushd tools/bpf/bpftool
> +make DESTDIR=%{buildroot} prefix=%{_prefix}
> bash_compdir=%{_sysconfdir}/bash_completion.d/ mandir=%{_mandir} install
> doc-install
> +popd
>
>  ###
>  ### scripts
> @@ -368,6 +381,14 @@ popd
>  %{_includedir}/cpufreq.h
>  %{_includedir}/cpuidle.h
>
> +%files -n bpftool
>

You need to add a %license here because it doesn't depend on the root
kernel-tools package which ships a license

+%{_sbindir}/bpftool
> +%{_sysconfdir}/bash_completion.d/bpftool
> +%{_mandir}/man8/bpftool-cgroup.8.gz
> +%{_mandir}/man8/bpftool-map.8.gz
> +%{_mandir}/man8/bpftool-prog.8.gz
> +%{_mandir}/man8/bpftool.8.gz
> +
>  %changelog
>  * Mon Mar 12 2018 Jeremy Cline  - 4.16.0-0.rc5.git0.1
>  - Linux 4.16-rc5
> --
> 2.13.6
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
>
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: /proc/sys/net/core/optmem_max on armv7l

[Peter Robinson]

> I just noticed, there is a difference in the default value of
> `/proc/sys/net/core/optmem_max` on armv7l:
>
> On all arches it is 20480, but on armv7l it is 10240.
>
> Is there any specific reason for limiting the maximum ancillary buffer
> size allowed per socket on this arch?

No specific reason, I think that would be an upstream kernel default,
I'm not aware we tweak that setting on any of the architectures so it
should be the arch default.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Common kernel problems page

[Peter Robinson]

On Tue, Jan 9, 2018 at 12:18 AM, Laura Abbott  wrote:
> On 01/08/2018 12:30 PM, Matthew Miller wrote:
>>
>> In helping someone with a suspend/resume problem, I came across this
>> page:
>>
>> * https://fedoraproject.org/wiki/Common_kernel_problems
>>
>> which looks awesome and super-helpful... and then I noticed that the
>> last edit is 2012, with the bulk of activity in 2010 or earlier.
>>
>> How relevant is the content on this page today? Should it just be
>> trashed, or can it be savaged? I'd love to see an updated version of
>> this as part of the (new/upcoming) Quick Docs at
>> .
>>
>
> Some of the more generic suggestions are still useful, the hardware
> specific parts probably need some updating, perhaps with new
> quirks. I could see this being expanded with some other common
> "here's how you get information X for problem Y" as well.

Probably useful to add some architecture bits there for the various
non x86 arches.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH 0/2] configs: Rename base-{generic,debug} to configs/fedora/

[Peter Robinson]

On Wed, Dec 20, 2017 at 5:39 PM, Don Zickus  wrote:
> On Wed, Dec 13, 2017 at 04:39:26PM -0500, Don Zickus wrote:
>> This patchset renames the configs/base-{generic,debug} to
>> configs/fedora/{generic,debug} and updates the scripts to reflect that.
>
> Hi Jarod, Peter,
>
> Does this approach work better?

It's a bit less annoying for tab completion, thanks, sorry for late
response, PTO and catchup :)

>> Because the configs rename patch is huge and Laura prefers not to have it
>> on the list, I am purposely excluding the content of that particular patch.
>>
>> The script changes are attached for public review.
>>
>> The code can be reviewed here:
>> https://pagure.io/fedora-kernel-dzickus.git rh_sync2
>>
>>
>> Don Zickus (2):
>>   configs: Move base-debug and base-generic to configs/fedora
>>   configs: Update config generation script to use configs/fedora
>>
>>  configs/build_configs.sh   | 62 
>> +++---
>>  configs/config_generation  |  5 ++
>>
>> 
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Current specfile misapplies v4.14.10 stable update for fc26

[Peter Robinson]

On Tue, Jan 2, 2018 at 11:56 PM, Paul Bolle  wrote:
> On Tue, 2018-01-02 at 17:27 -0500, Josh Boyer wrote:
>> If you're talking about local builds, it isn't tricky at all.  Someone
>> would just need to adjust the kernel.spec to do it and/or write steps
>> to have your local git tree in a state that the existing spec could
>> use.  You could even use the existing exploded tree because the
>> configs are all there as well.
>
> If the end result is something that closely tracks kernel.git that sounds
> rather nice. (Even better would be a tree that kernel.git itself uses, but now
> I'm getting carried away a bit.)
>
> I should try to create something that somehow-sort-of does what I want first,
> I guess. Bother. I'd rather just snap my fingers!
>
>> If you're talking about building Fedora kernels officially from an
>> exploded tree, there are two tricky issues.
>>
>> 1) You still have to at least create a tarball and upload that because
>> koji can't build from exploded source.  That means you're uploading a
>> massive tarball every day and it's terrible.
>
> But koji isn't carved in stone, is it?

No, but in the current status quo it can't pull from random sources
(Fedora config, not koji in general), this is an explicit decision for
audit and related requirements so what goes into a build can be
reproduced and reviewed.

>> 2) The tracking of patches Fedora carries on top of upstream results
>> in forced rebases.  You see that with the existing exploded tree we
>> have on kernel.org, but that literally is just an exploded tree of
>> builds.  It's not really great for development.  For development
>> purposes, the forced rebases makes it really crappy to work with.  The
>> alternative is a ton of merges, which would be possible but alas is
>> not great either.
>
> Sorry, I'm only consuming the kernel.git efforts, so it's hard for me to truly
>   understand the effort involved.
>
> Thanks for taking the time to respond to my semi-cooked ideas!
>
>
> Paul Bolle
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: kernel-4.15.0-0.rc3.git0.1.fc28 src rpm fails to compile because of errors in ppc64p7 config file

[Peter Robinson]

>> On Wed, Dec 13, 2017 at 8:08 PM, Laura Abbott 
>> wrote:
>
>> > Can you share the steps you used to produce this build as well as
>> > the full build log? As you noted, this was built successfully in
>> > koji.
>
> I'm following this procedure for building from the src.rpm using
> rpmbuild.
>
> https://fedoraproject.org/wiki/Building_a_custom_kernel/Source_RPM
>
> I've been using it for years, and I successfully built a 4.15 kernel
> just a few weeks ago using the same procedure.
>
>> The ppc64p7 sub variant was removed so I'm not even sure why that's
>> showing up.
>
> This was the key comment.  It seems that the kernel picks up any kernel
> config files in SOURCES.  There was an old set of configs for ppc64p7
> there.  Once I deleted them, everything worked fine.  The previous
> version of 4.15 I successfully built was in F25, and I'm now building in
> rawhide, and it had the obsolete ppc64p7 config file I SOURCES from
> older builds.
>
> Sorry for the noise, but thanks for the help.

No issues, I always find "git status" is a big help here with kernel
stuff, especially when it comes to stuff that might be generated.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: kernel-4.15.0-0.rc3.git0.1.fc28 src rpm fails to compile because of errors in ppc64p7 config file

[Peter Robinson]

On Wed, Dec 13, 2017 at 8:08 PM, Laura Abbott  wrote:
> On 12/13/2017 10:25 AM, stan wrote:
>>
>>
>> I tried to compile this kernel from the src rpm on rawhide.  I kept
>> getting the error that two config options for ppc64p7 were set to m,
>> and m wasn't a valid choice.
>>
>> So, I generated the following patch,
>>
>> diff --git a/configs/kernel-4.15.0-ppc64p7.config
>> b/configs/kernel-4.15.0-ppc64p7.config index 18f4b44..ca5b410 100644
>> --- a/configs/kernel-4.15.0-ppc64p7.config
>> +++ b/configs/kernel-4.15.0-ppc64p7.config
>> @@ -1704,7 +1704,7 @@ CONFIG_HW_RANDOM_TIMERIOMEM=m
>>   CONFIG_HW_RANDOM_TPM=m
>>   CONFIG_HW_RANDOM_VIRTIO=m
>>   CONFIG_HW_RANDOM=y
>> -CONFIG_HWSPINLOCK=m
>> +CONFIG_HWSPINLOCK=y
>>   CONFIG_HYSDN_CAPI=y
>>   CONFIG_HYSDN=m
>>   CONFIG_HZ=100
>> @@ -4447,7 +4447,7 @@ CONFIG_SND_DARLA24=m
>>   # CONFIG_SND_DEBUG_VERBOSE is not set
>>   CONFIG_SND_DEBUG=y
>>   CONFIG_SND_DESIGNWARE_I2S=m
>> -CONFIG_SND_DESIGNWARE_PCM=m
>> +CONFIG_SND_DESIGNWARE_PCM=y
>>   CONFIG_SND_DICE=m
>>   CONFIG_SND_DMAENGINE_PCM=m
>>   CONFIG_SND_DRIVERS=y
>>
>> I don't know if y is a valid setting for a ppc for those options, but I
>> presume if m was desired, y would succeed.  I don't really care about
>> ppc64p7 as I'm building for x86_64.  I changed the spec file so that
>> this architecture won't be built in nobuildarches, and this error still
>> occurred.
>>
>> Unfortunately, at the time that the kernel is patched, this config file
>> doesn't exist yet, and so the patch fails.  I see a successful build in
>> koji; I'm not sure how that can be.
>>
>> What is the best way to proceed from here?
>
>
> Can you share the steps you used to produce this build as well as the
> full build log? As you noted, this was built successfully in koji.

The ppc64p7 sub variant was removed so I'm not even sure why that's showing up.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Updating config option layout and scripts

[Peter Robinson]

On Wed, Dec 6, 2017 at 2:17 PM, Don Zickus  wrote:
> On Wed, Dec 06, 2017 at 05:34:18AM +0000, Peter Robinson wrote:
>> On Mon, Nov 13, 2017 at 5:42 PM, Laura Abbott  wrote:
>> > On 11/10/2017 11:48 AM, Don Zickus wrote:
>> >>
>> >> Hi Laura,
>> >>
>> >> As per our conversation, here is my pull request for the config changes:
>> >> https://pagure.io/fedora-kernel-dzickus.git rh_sync
>> >>
>> >>
>> >> As part of an effort to foster better cross collaboration with internal
>> >> Red
>> >> Hat kernels, align the configs layout to match that kernel.  This will
>> >> allow
>> >> Red Hat engineers to provide easier guidance on how to set various config
>> >> options.
>> >>
>> >> In addition, the scripts that process the config options will migrate to
>> >> the
>> >> configs/ directory too.  Future config workflows will stage all work in
>> >> the
>> >> configs/ area.
>> >>
>> >> A simple diff between the kernels will easily expose which config options
>> >> are different.  Reading the comments in the file provides guidance to
>> >> Fedora
>> >> to determine if that kernel should make a similar change or not.  While
>> >> the
>> >> RH kernel stays internal, requested changes will be posted publicly for
>> >> review with said reason.
>> >>
>> >> Rename debugconfig -> configs/base-debug
>> >> Rename baseconfig -> configs/base-generic
>>
>> Any chance we could drop the base- in those names and just have
>> configs/debug/
>> configs/generic
>>
>> The base- is somewhat superfluous and is annoying for auto complete ;-)
>
> It is, but was specifically added so kernels that want to do overrides like
> RHEL could add their own custom configs/debug and configs/generic.
>
> I am open to name changes but the goal was to use Fedora configs as a base
> and then allow the ability to override through other directories.

I don't see how 's/base-//' would stop the ability for overrides? Do
you have an explicit example of how you see that working?

> So if you have a proposal to allow that, I am open to it. :-)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: HID_CP2112 is not set in the Fedora kernel config

[Peter Robinson]

On Wed, Dec 6, 2017 at 9:52 AM, Christoph M.  wrote:
> Hi Fedora kernel team,
>
> today I've received a CP2112 based USB-to-I2C adapter board
> to interact with some I2C devices. I've chosen an adpater based
> on that chip since it has a mainline Linux driver.
>
> To my surprise the adapter was not working, because the
> config file of the Fedora kernel has HID_CP2112 not set
> (I've checked /boot/config-4.13.16-302.fc27.x86_64).
>
> Recompiling a kernel is not an issue for me, but doing that
> regularly might get a bit cumbersome at some point.
>
> Therefore I'd like to ask if there is a specific reason why this
> kernel config option is not enabled in the Fedora kernel and
> what would be necessary to get this enabled by default?

Probably because no one has requested it to date, I'll enable it in
4.14+ in F-27+ and it should land back into F-26 once it gets 4.14
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Updating config option layout and scripts

[Peter Robinson]

On Mon, Nov 13, 2017 at 5:42 PM, Laura Abbott  wrote:
> On 11/10/2017 11:48 AM, Don Zickus wrote:
>>
>> Hi Laura,
>>
>> As per our conversation, here is my pull request for the config changes:
>> https://pagure.io/fedora-kernel-dzickus.git rh_sync
>>
>>
>> As part of an effort to foster better cross collaboration with internal
>> Red
>> Hat kernels, align the configs layout to match that kernel.  This will
>> allow
>> Red Hat engineers to provide easier guidance on how to set various config
>> options.
>>
>> In addition, the scripts that process the config options will migrate to
>> the
>> configs/ directory too.  Future config workflows will stage all work in
>> the
>> configs/ area.
>>
>> A simple diff between the kernels will easily expose which config options
>> are different.  Reading the comments in the file provides guidance to
>> Fedora
>> to determine if that kernel should make a similar change or not.  While
>> the
>> RH kernel stays internal, requested changes will be posted publicly for
>> review with said reason.
>>
>> Rename debugconfig -> configs/base-debug
>> Rename baseconfig -> configs/base-generic

Any chance we could drop the base- in those names and just have
configs/debug/
configs/generic

The base- is somewhat superfluous and is annoying for auto complete ;-)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: invalid signature error with 4.15rc1

[Peter Robinson]

On Wed, Nov 29, 2017 at 6:56 PM, Chris Murphy  wrote:
> 4.15.0-0.rc1.git0.1.fc28.x86_64 is in koji and it will not boot with
> Secure Boot enabled. I get an error from GRUB after choosing the boot
> entry, that it has an invalid signature and the kernel needs to be
> loaded first.

It wasn't signed, that's why it had a tagging error in koji, I presume
you downloaded it from koji.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Reviving the hardware census

[Peter Robinson]

On Tue, Nov 7, 2017 at 10:49 PM, Jeremy Cline  wrote:
> Hey folks,
>
> For some time now, Fedora has operated without a database of hardware
> users have. Smolt, the old hardware database, was retired in 2012[0] and
> its intended successor[1] was never deployed by Fedora Infrastructure.
>
> It would be nice to have a hardware database, so I (and hopefully some
> others) would like to get Census up and running for Fedora. Before we
> look at deploying Census, however, it would be good to make sure it has
> everything we need.
>
> Census has client plugins to collect information[2]. At the moment, it
> has plugins for:
>
> * The vendor, device, subsystem_vendor, subsystem_device, and class from
>   each PCI device
>
> * The idVendor, idProduct, bcdDevice, and bDeviceClass for USB devices
>   as well as the bInterfaceClass, bInterfaceSubClass, and
>   bInterfaceProtocol for each interface
>
> * The contents of /etc/os-release
>
> * All the RPMs installed on a system
>
> Other than the drivers bound to the PCI and USB devices (which is an
> open PR[3]), what else would be good to collect?

On ARM any platform "SoC attached" would be useful else you'll get
almost nothing as most NICs/SATA/storage/GPU/cameras etc are generally
not attached via USB/PCI. This would also include things like SDIO
(for wifi), and I suppose i2c/gpio would be useful in that context
too.

Peter
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Changing the SND_HDA_POWER_SAVE_DEFAULT option from 0 to 1

[Peter Robinson]

On Wed, Nov 1, 2017 at 6:09 PM, Hans de Goede  wrote:
> Hi All,
>
> I'm working on trying to improve the OOTB power-consumption
> of Fedora Workstation on laptops.
>
> One of the easy wins here is setting snd_hda_intel.power_save=1,
> which saves about 0.4W which given that modern laptops idle at
> around 6-8W is a significant saving.
>
> I've asked the upstream kernel devs if there are any downsides
> to setting SND_HDA_POWER_SAVE_DEFAULT=1 and I got a reply that
> this should be fine and that OpenSUSE Tumbleweed is already
> doing this.
>
> So unless there are any objections I would like to change this
> option to 1 starting with 4.14 kernel. Is that ok ?

None from me and easy enough to revert if it proves a problem, is
there a way to change the default at run time?
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] Move CONFIG_USB_CHIPIDEA for all armv7

[Peter Robinson]

On Thu, Sep 28, 2017 at 4:55 PM, Nicolas Chauvet  wrote:
> Since kernel 4.14-rc1, this allows USB Device Controller (UDC) on jetson-tk1
> Move this config to all armv7 so lpae also has it.
> Tested on jetson-tk1 and paz00

I pushed something slightly different to this to have the config in
the base ARM across all variants, I thought I had actually already
done this.

Cheers,
Peter
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Patch for trimslices on 4.13+

[Peter Robinson]

Pushed

On Mon, Sep 25, 2017 at 2:25 PM, Nicolas Chauvet  wrote:
> Hi,
>
>
> This patch fixes pcie on tegra20. This affects trimslice ethernet
> usage (there is no network) on kernel 4.13+
> https://marc.info/?l=linux-pci&m=150614748008380&w=2
>
> While speaking about trimslice. I would like to consider dropping
> ARM-tegra-usb-no-reset.patch because this patch is unneeded anymore
> with any kernel/bootloader. It also prevent other tegra-ehci devices
> to enter suspend.
>
> I can submit patches if needed for both... (However I don't know if
> it's won't be better for the patches to be submitted on the kernel
> tree with source+fedora-patches (1) or the distgit version ?).
>
> (1) https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/
>
> Thx
>
>
> --
> -
>
> Nicolas (kwizart)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCHv2 00/14] arm64: VMAP_STACK support

[Peter Robinson]

On Mon, Sep 4, 2017 at 2:00 AM, Jon Masters  wrote:
> Can you enable CONFIG_VMAP_STACK for aarch64 kernels once this lands in
> 4.14? I'd like to see any problems flagged early and often on this...

This is now enabled. Is there anything in particular we should be
looking for here in terms of possible problems? Just useful to get a
rough idea for those on the ground.

P


>  Forwarded Message 
> Subject: [PATCHv2 00/14] arm64: VMAP_STACK support
> Date: Tue, 15 Aug 2017 13:50:35 +0100
> From: Mark Rutland 
> To: linux-arm-ker...@lists.infradead.org
> CC: ard.biesheu...@linaro.org, catalin.mari...@arm.com,
> james.mo...@arm.com, labb...@redhat.com, linux-ker...@vger.kernel.org,
> l...@amacapital.net, mark.rutl...@arm.com, m...@codeblueprint.co.uk,
> will.dea...@arm.com, kernel-harden...@lists.openwall.com,
> keesc...@chromium.org
>
> Hi,
>
> Ard and I have worked together to implement vmap stack support for
> arm64. This supersedes our earlier vmap stack RFCs [0,1]. The git author
> stats are a little misleading, as I've teased parts out into smaller
> patches for review.
>
> The series is based on our stack dump rework [2,3], which can be found
> in the arm64/exception-stack branch [4] of my kernel.org repo. This
> series can be found in the arm64/vmap-stack branch [5] of the same repo.
>
> Since v1 [6]:
> * Fix typos
> * Update comments in entry assembly
> * Dump exception context (and stacks) before regs
> * Define safe adr_this_cpu for modules
>
> On arm64, there is no double-fault exception, as software saves
> exception context to the stack. An erroneous memory access taken during
> exception handling results in a data abort, as with any other erroneous
> memory access. To avoid taking these recursively, we must detect
> overflow by checking the SP before we attempt to store any context to
> the stack. Doing this efficiently requires a couple of tricks.
>
> For a naturally aligned stack, bits THREAD_SHIFT-1:0 of a valid SP may
> contain any arbitrary value:
>
> 0bXX .. 11
> 0bXX .. 11011001011100
> 0bXX .. 00
>
> By aligning stacks to double their natural alignment, we know that the
> THREAD_SHIFT bit of any valid SP must be zero:
>
> 0bXX .. 0 11
> 0bXX .. 0 11011001011100
> 0bXX .. 0 00
>
> ... while an overflow will result in this bit flipping, along with
> (some) other high-order bits:
>
> 0bXX .. 0 00
> < SP -= 1 >
> 0bXX .. 1 11
>
> ... and thus, we can detect overflows of up to THREAD_SIZE by testing
> the THREAD_SHIFT bit of the SP value.
>
> Provided we can get the SP into a general purpose register, we can
> perform this test with a single TBNZ instruction. We don't have scratch
> space to store a GPR, but we can (partially) swap the SP with a GPR
> using arithmetic to perform the test:
>
> add sp, sp, x0  // sp' = sp + x0
> sub x0, sp, x0  // x0' = sp' - x0 = (sp + x0) - x0 = 
> sp
> tbnzx0, #THREAD_SHIFT, overflow_handler
> sub x0, sp, x0  // sp' - x0' = (sp + x0) - sp = x0
> sub sp, sp, x0  // sp' - x0 = (sp + x0) - x0 = sp
>
> This series implements this approach, along with the other requisite
> changes required to make this work.
>
> The SP test is performed for all exceptions, after compensating for the
> size of the exception registers, allowing the original exception context
> to be preserved in entirety. The tests themselves are folded into the
> exception vectors, minimizing their impact.
>
> To ensure that IRQ stack overflows are detected and handled, IRQ stacks
> are now dynamically allocated, with guard pages.
>
> I've given the series some light testing with LKDTM, Syzkaller, Vince
> Weaver's perf fuzzer, and a few combinations of debug options. I haven't
> compared performance of the entire series to a baseline kernel, but from
> testing so far the cost of the SP test falls in the noise for a kernel
> build workload on Cortex-A57.
>
> Many thanks to Ard for putting up with my meddling, and also to Laura,
> James, Catalin, and Will for comments and testing.
>
> Thanks,
> Mark.
>
> [0]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/518368.html
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/518434.html
> [2]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/520705.html
> [3]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/521435.html
> [4] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
> arm64/exception-stack
> [5] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
> arm64/vmap-stack
> [6]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/524179.html
>
> Ard Biesheuvel (2):
>   arm64: kernel: remove {THREAD,IRQ_STACK}_START_SP
>   arm64: assembler: allow adr_this_cpu to use the stack pointer
>
> Ma

Re: [X86] x86 Architecture SIG

[Peter Robinson]

On Mon, Sep 11, 2017 at 6:43 PM, Josh Boyer  wrote:
> On Mon, Sep 11, 2017 at 1:22 PM, Justin Forbes  wrote:
>> On Fri, Sep 8, 2017 at 9:41 PM, Jeff Backus  wrote:
>>
>>> (Apologies - resending because I wasn't subscribed earlier)
>>>
>>> Hi list,
>>>
>>> I'm contacting you on behalf of the x86 SIG. Today FESCo approved our
>>> request to continue to support Fedora on x86 hardware, provided that we do
>>> our part to keep things running.
>>>
>>> I encourage you to reach out to us when things do come up. You can find us
>>> at x...@lists.fedoraproject.org or on #fedora-x86. We will likewise try to
>>> be proactive in tracking down and triaging x86-related issues as well as
>>> helping test and debug things.
>>>
>>> One caveat that FESCo attached to our request is that if you, the kernel
>>> team are cleared to treat i686 as any other secondary arch when you run
>>> into build issues. That is, you are allowed to ExcludeArch i686 until these
>>> issues are resolved. We ask that you block FE-ExcludeArch-x86 so that we
>>> can track these issues.
>>>
>>> Happy to do so.  There wasn't much need on the current issue because there
>> are other problems keeping us from getting a successful build just yet.
>> Yay, merge window. I really appreciate the SIG stepping forward and finding
>> the solution for i686 though in a timely manner.
>>
>> Additionally, FESCo would like us to establish a minimum level of hardware
>>> supported. We are working on this list and will follow up with you once we
>>> have it completed. In the interim, we did want to address a couple of
>>> concerns that were passed along by Stephen Smoogen:
>>>
>>> * We have decided to drop support for PAE, so please feel free to disable
>>> it on the next build
>>> * We have decided to continue to support pre-SSE2 hardware for the time
>>> being
>>
>>
>> Done, rawhide going forward will drop PAE. Current stable Fedora releases
>> will continue to build PAE as it wouldn't be wise to drop support on an
>> existing release.
>
> This might require changes in Anaconda.  IIRC, it will look at the
> cpuflags during install and look to install the PAE kernel if that
> flag is present.  Unless the standard i686 kernel does a fake
> Provides, it might cause install issues if it's missing.  At least
> worth verifying.

I'm pretty sure it will, it'll also need changes in the lorax templates.

Peter
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org