Re: [OS-BUILD PATCH 0/0] fedora: a bunch of stuff for 6.11
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3302#note_2024772394 Yes, It seems to be working fine on my machine as well. I didn't put it in the initrd. -- ___ 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: [OS-BUILD PATCH 0/0] fedora: a bunch of stuff for 6.11
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3302#note_2023354472 Do we know what happens on the x13s when both the kernel and userspace pd mapper are enabled? (I'm testing it now.. but its building on device so will take an hour or so) -- ___ 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: [OS-BUILD PATCH 0/0] fedora: a bunch of stuff for 6.11
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3302#note_2023354472 Do we know what happens on the x13s when both the kernel and userspace pd mapper are enabled? -- ___ 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: [OS-BUILD PATCH 0/0] all: cleanup MEDIA_CONTROLLER options
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3263#note_2008484611 The external contributor tag is presumably because you don't have a redhat.com addr (or didn't sign in?) Also the commit message has a "Digutal" in it. But otherwise looks fine to me 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv2 0/0] fedora: cleanups and new enablement
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2926#note_1767163098 This looks sane to me 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCH] redhat/configs: For aarch64/RT, default kstack randomization off
From: Jeremy Linton redhat/configs: For aarch64/RT, default kstack randomization off Unlike other architectures which use their cycles counters to seed the kstack randomization (which is sketchy) aarch64 uses the kernel random number generator. For a list of reasons starting with the lack of an enabled/fast cycle counter, a ubiquitous high frequency timer, nor machines which have the v8.5 FEAT_RNG. Using the kernel rng is largely an acceptable solution except for RT workloads which can experience quite large latency spikes as a result. So, lets invert the default kstack randomization for RT kernels on aarch64 until FEAT_RNG is common or a better solution is found. Signed-off-by: Jeremy Linton diff --git a/redhat/configs/common/rt/generic/arm/aarch64/CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT b/redhat/configs/common/rt/generic/arm/aarch64/CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/common/rt/generic/arm/aarch64/CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT @@ -0,0 +1 @@ +# CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2933 -- ___ 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: [OS-BUILD PATCH] redhat/configs: aarch64: move CONFIG_ROCKCHIP_ERRATUM_3588001 to common
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2526#note_1442679421 Yes, I think this one leaked in and should probably be off as pbrobinson mentions above because its dead code. There is a UEFI/ACPI RK3588 port floating around, but given all the current issues, its probably best to leave it off until someone formally assures one of those works, and then flips all the corresponding drivers (looks like a nic and a couple other things at a minimum). ___ 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
[OS-BUILD PATCH] redhat/configs: Disable qcom armv7 drippings in the aarch64 tree
From: Jeremy Linton redhat/configs: Disable qcom armv7 drippings in the aarch64 tree There are a few global clock controller (GCC), MMC, and phy modules for some old armv7 qcom soc's still being statically built for the aarch64 kernel. Lets disable them as AFAIK they aren't being used by newer SOCs we support. Signed-off-by: Jeremy Linton diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_APQ_GCC_8084 b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_APQ_GCC_8084 index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_APQ_GCC_8084 +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_APQ_GCC_8084 @@ -1 +1 @@ -CONFIG_APQ_GCC_8084=y +# CONFIG_APQ_GCC_8084 is not set diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_APQ_MMCC_8084 b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_APQ_MMCC_8084 index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_APQ_MMCC_8084 +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_APQ_MMCC_8084 @@ -1 +1 @@ -CONFIG_APQ_MMCC_8084=m +# CONFIG_APQ_MMCC_8084 is not set diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_DRM_MSM_DSI_28NM_8960_PHY b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_DRM_MSM_DSI_28NM_8960_PHY index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_DRM_MSM_DSI_28NM_8960_PHY +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_DRM_MSM_DSI_28NM_8960_PHY @@ -1 +1 @@ -CONFIG_DRM_MSM_DSI_28NM_8960_PHY=y +# CONFIG_DRM_MSM_DSI_28NM_8960_PHY is not set diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_GCC_8660 b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_GCC_8660 index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_GCC_8660 +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_GCC_8660 @@ -1 +1 @@ -CONFIG_MSM_GCC_8660=y +# CONFIG_MSM_GCC_8660 is not set diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_GCC_8960 b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_GCC_8960 index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_GCC_8960 +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_GCC_8960 @@ -1 +1 @@ -CONFIG_MSM_GCC_8960=y +# CONFIG_MSM_GCC_8960 is not set diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_GCC_8974 b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_GCC_8974 index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_GCC_8974 +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_GCC_8974 @@ -1 +1 @@ -CONFIG_MSM_GCC_8974=y +# CONFIG_MSM_GCC_8974 is not set diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_MMCC_8960 b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_MMCC_8960 index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_MMCC_8960 +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_MMCC_8960 @@ -1 +1 @@ -CONFIG_MSM_MMCC_8960=m +# CONFIG_MSM_MMCC_8960 is not set diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_MMCC_8974 b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_MMCC_8974 index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_MMCC_8974 +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_MSM_MMCC_8974 @@ -1 +1 @@ -CONFIG_MSM_MMCC_8974=m +# CONFIG_MSM_MMCC_8974 is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2513 ___ 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: [OS-BUILD PATCH 0/0] ark: enable wifi on aarch64
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2154#note_1234624744 Presumably, a small selection of usb->wifi/etc and a couple rpi4 like devices would suffice? ___ 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
Hi, On 12/8/22 06:58, Peter Robinson wrote: 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. Ok, I have a couple ideas, but they start with the question, why do we need fully accelerated graphics for an installer (live image excepted) that works nearly as well in text mode? That gets the GPU firmware off the install ramdisk. Just being a bit more fine grained with the firmware package and only installing the pieces needed by the running machine shrinks could shrink the footprint too. Something that looks for kernel firmware load errors, and installs a package solves the issue of HW that has been dynamically added after the fact (of course disk/network card firmware would still be needed by the installer). Although, just doing per arch firmware shrinks it too. Both the x86 and arm64 packages are both 177M, and it seems unlikely my arm machine needs amd microcode, or that my amd needs the dpaa firmware or firmware specific to some arm SBCs. So, ideas, but then someone needs to spend
[OS-BUILD PATCH] [redhat] configs: Fix Layerscape regression
From: Jeremy Linton [redhat] configs: Fix Layerscape regression CONFIG_NXP now hides the NXP devices, which in the case of the LX2k series is a tested fedora platform. Without enabling CONFIG_NXP these platforms stop working because the lack of CONFIG_LAYERSCAPE disables their drivers. Cc: Mark Salter Cc: Mark Langsdorf Cc: Fedora Kernel Team Signed-off-by: Jeremy Linton diff --git a/redhat/configs/pending-fedora/generic/CONFIG_ARCH_NXP b/redhat/configs/pending-fedora/generic/CONFIG_ARCH_NXP index blahblah..blahblah 100644 --- a/redhat/configs/pending-fedora/generic/CONFIG_ARCH_NXP +++ b/redhat/configs/pending-fedora/generic/CONFIG_ARCH_NXP @@ -8,4 +8,4 @@ # # # -# CONFIG_ARCH_NXP is not set +CONFIG_ARCH_NXP=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2129 ___ 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
[OS-BUILD PATCH] redhat: configs: Disable FIE on arm
From: Jeremy Linton redhat: configs: Disable FIE on arm FIE intends to estimate cpu work for a given task more accurately. On an ACPI/CPPC machine, the code can utilize PCC mailboxes that trap to the firmware (which are all the CPPC machines at this point). Meaning the CPU overhead of this feature far outweighs any potential benefit. The default is being changed upstream, along with some related code changes, but until the benefit is proven, it should be disabled in all fedora releases. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2012226 Signed-off-by: Jeremy Linton diff --git a/redhat/configs/fedora/generic/arm/CONFIG_ACPI_CPPC_CPUFREQ_FIE b/redhat/configs/fedora/generic/arm/CONFIG_ACPI_CPPC_CPUFREQ_FIE index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/arm/CONFIG_ACPI_CPPC_CPUFREQ_FIE +++ b/redhat/configs/fedora/generic/arm/CONFIG_ACPI_CPPC_CPUFREQ_FIE @@ -1 +1 @@ -CONFIG_ACPI_CPPC_CPUFREQ_FIE=y +# CONFIG_ACPI_CPPC_CPUFREQ_FIE is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1990 ___ 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
[OS-BUILD PATCH] [redhat] arm: turn SPE back on
From: Jeremy Linton
[redhat] arm: turn SPE back on
While attempting to turn SPE on for all redhat distros
except for armv7 builds, the enable/disable was inverted
and it was left disabled for everything except for armv7.
This was incorrect, lets fix it.
Fixes: d76aee99af90 ("[redhat] arm: move SPE to generic")
Signed-off-by: Jeremy Linton
diff --git a/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM_SPE_PMU
b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM_SPE_PMU
index blahblah..blahblah 100644
--- a/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM_SPE_PMU
+++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM_SPE_PMU
@@ -1 +1 @@
-# CONFIG_ARM_SPE_PMU is not set
+CONFIG_ARM_SPE_PMU=m
diff --git a/redhat/configs/common/generic/arm/armv7/CONFIG_ARM_SPE_PMU
b/redhat/configs/common/generic/arm/armv7/CONFIG_ARM_SPE_PMU
index blahblah..blahblah 100644
--- a/redhat/configs/common/generic/arm/armv7/CONFIG_ARM_SPE_PMU
+++ b/redhat/configs/common/generic/arm/armv7/CONFIG_ARM_SPE_PMU
@@ -1 +1 @@
-CONFIG_ARM_SPE_PMU=m
+# CONFIG_ARM_SPE_PMU is not set
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1745
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2 0/2] redhat/configs: Enable HYPERV host support on aarch64
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1393#note_781394705 INPUT_MATRIXKMAP gets triggered because of KEYBOARD_TEGRA which is selected because CONFIG_ARCH_TEGRA is on. Those choices seem fairly reasonable IMHO if TEGRA is enabled (which it is). ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2 0/2] redhat/configs: Enable HYPERV host support on aarch64
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1393#note_777928842 No, I removed the ark override on CONFIG_KEYBOARD then moved the missing definitions from fedora to common. Which makes them the same. ___ 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/configs: enable CONFIG_INPUT_KEYBOARD for AARCH64
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1529#note_777597493 See also https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1525 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2 0/2] redhat/configs: Enable HYPERV host support on aarch64
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1393#note_777596635 which is similar but not identical to https://gitlab.com/cki-project/kernel- ark/-/merge_requests/1525 I opened. The difference is that I'm honoring the fedora config for the keyboards, I'm not sure what your doing there is the right way if you want to differentiate fedora from the ark config. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2 0/2] redhat/configs: Enable HYPERV host support on aarch64
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1393#note_774807936 The merged config options don't appear to be complete, in my testing the at keyboard is required by the hyperv_keyboard driver to actually enable the keyboard. Hence why I opened 1525 by itself. But I have to ask, Is the ampere box running a released version of windows, because AFAIK we have all these arm laptops/etc in the field and right now, because hypervisor fix isn't yet released, they don't work, which is a bit off a bad look. It might be nice if fedora+centos worked for the next few months until MS fixes hyperv on those machines. I wish there was a way to tag the "workaround" as having a 6 month lifetime/etc, but I don't know how to pull that off. ___ 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/configs: Fixup HYPERV config on aarch64
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1525#note_772087081 This MR is just the CONFIG_ changes for arm64/hyperv. There is another older one which was originally just the CONFIG changes until I was able to test them, and now includes a non mainline patch required to make it work as well https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1393. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2 0/2] redhat/configs: Enable HYPERV host support on aarch64
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1393#note_772080204 well just to confuse everyone, I pushed the entire patch set required to get hyperv working here. That includes the config and the out of tree fix. So, either this MR or the other one can be merged depending on whether we want to just pick up the correct CONFIG_ options, or pick up the CONFIG_ options and the temp patch required to get it to actually work until MS releases updated hypervisors. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv2 2/2] NOT_UPSTREAM/HYPERV: Enable HYPERV_TIMER on ARM64
From: Jeremy Linton
NOT_UPSTREAM/HYPERV: Enable HYPERV_TIMER on ARM64
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2007430
Upstream Status: RHEL-only
The existing windows/arm64 hyperv host expects that HYPERV_TIMER
is enabled by the linux guests (as x86), and so guests that
aren't utilizing this will fail to boot fairly early in the
boot cycle. Other linux/distro/kernel's being distributed by
MS/etc have a patch similar to this one in their tree. Its
been indicated to me that the host will eventually be fixed but
for the time being that isn't the case and anyone with a
publically available windows/arm machine can't boot fedora and
centos kernel's provided because of this.
Originally-by: Michael Kelley
Tweaked to support !hyperv guest enviroments by Jeremy Linton
Signed-off-by: Jeremy Linton
diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index blahblah..blahblah 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -19,12 +19,11 @@
static bool hyperv_initialized;
-static int __init hyperv_init(void)
+void __init hyperv_early_init(void)
{
struct hv_get_vp_registers_output result;
u32 a, b, c, d;
u64 guest_id;
- int ret;
/*
* Allow for a kernel built with CONFIG_HYPERV to be running in
@@ -32,10 +31,10 @@ static int __init hyperv_init(void)
* In such cases, do nothing and return success.
*/
if (acpi_disabled)
- return 0;
+ return;
if (strncmp((char *)&acpi_gbl_FADT.hypervisor_id, "MsHyperV", 8))
- return 0;
+ return;
/* Setup the guest ID */
guest_id = generate_guest_id(0, LINUX_VERSION_CODE, 0);
@@ -63,6 +62,16 @@ static int __init hyperv_init(void)
pr_info("Hyper-V: Host Build %d.%d.%d.%d-%d-%d\n",
b >> 16, b & 0x, a, d & 0xFF, c, d >> 24);
+ hyperv_initialized = true;
+}
+
+static int __init hyperv_init(void)
+{
+ int ret;
+
+ if (!hyperv_initialized)
+ return 0;
+
ret = hv_common_init();
if (ret)
return ret;
@@ -74,7 +83,6 @@ static int __init hyperv_init(void)
return ret;
}
- hyperv_initialized = true;
return 0;
}
diff --git a/arch/arm64/include/asm/mshyperv.h
b/arch/arm64/include/asm/mshyperv.h
index blahblah..blahblah 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -21,6 +21,13 @@
#include
#include
#include
+#include
+
+#if IS_ENABLED(CONFIG_HYPERV)
+void __init hyperv_early_init(void);
+#else
+static inline void hyperv_early_init(void) {};
+#endif
/*
* Declare calls to get and set Hyper-V VP register values on ARM64, which
@@ -41,6 +48,17 @@ static inline u64 hv_get_register(unsigned int reg)
return hv_get_vpreg(reg);
}
+/* Define the interrupt ID used by STIMER0 Direct Mode interrupts. This
+ * value can't come from ACPI tables because it is needed before the
+ * Linux ACPI subsystem is initialized.
+ */
+#define HYPERV_STIMER0_VECTOR 31
+
+static inline u64 hv_get_raw_timer(void)
+{
+ return arch_timer_read_counter();
+}
+
/* SMCCC hypercall parameters */
#define HV_SMCCC_FUNC_NUMBER 1
#define HV_FUNC_ID ARM_SMCCC_CALL_VAL( \
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index blahblah..blahblah 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
static int num_standard_resources;
@@ -347,6 +348,9 @@ void __init __no_sanitize_address setup_arch(char
**cmdline_p)
if (acpi_disabled)
unflatten_device_tree();
+ /* Do after acpi_boot_table_init() so local FADT is available */
+ hyperv_early_init();
+
bootmem_init();
kasan_init();
diff --git a/drivers/clocksource/hyperv_timer.c
b/drivers/clocksource/hyperv_timer.c
index blahblah..blahblah 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -566,3 +566,17 @@ void __init hv_init_clocksource(void)
hv_setup_sched_clock(read_hv_sched_clock_msr);
}
EXPORT_SYMBOL_GPL(hv_init_clocksource);
+
+/* Initialize everything on ARM64 */
+static int __init hyperv_timer_init(struct acpi_table_header *table)
+{
+ if (!hv_is_hyperv_initialized())
+ return -EINVAL;
+
+ hv_init_clocksource();
+ if (hv_stimer_alloc(true))
+ return -EINVAL;
+
+ return 0;
+}
+TIMER_ACPI_DECLARE(hyperv, ACPI_SIG_GTDT, hyperv_timer_init);
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index blahblah..blahblah 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -14,7 +14,7 @@ config HYPERV
system.
config HYPERV_TIMER
- def_bool HYP
[OS-BUILD PATCHv2 0/2] redhat/configs: Enable HYPERV host support on aarch64
From: Jeremy Linton on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1393 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2007430 Upstream Status: RHEL-only Windows on Arm is a thing, and some of those machines support HYPERV. For WoA users it would be helpful if Fedora/etc ran well as a guest OS. Signed-off-by: Jeremy Linton --- arch/arm64/hyperv/mshyperv.c | 18 +++-- arch/arm64/include/asm/mshyperv.h | 18 ++ arch/arm64/kernel/setup.c | 4 ++ drivers/clocksource/hyperv_timer.c | 14 +++ drivers/hv/Kconfig | 2 +- redhat/configs/ark/generic/arm/aarch64/CONFIG_INPUT_KEYBOARD | 1 - redhat/configs/common/generic/arm/aarch64/CONFIG_KEYBOARD_ATKBD | 1 + redhat/configs/common/generic/arm/aarch64/CONFIG_SERIO_LIBPS2 | 1 + redhat/configs/fedora/generic/arm/CONFIG_INPUT_MATRIXKMAP => redhat/configs/common/generic/arm/CONFIG_INPUT_MATRIXKMAP | 0 redhat/configs/fedora/generic/arm/CONFIG_KEYBOARD_TEGRA => redhat/configs/common/generic/arm/CONFIG_KEYBOARD_TEGRA | 0 10 files changed, 52 insertions(+), 7 deletions(-) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv2 1/2] redhat/configs: Fixup HYPERV config on aarch64
From: Jeremy Linton redhat/configs: Fixup HYPERV config on aarch64 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2007430 Upstream Status: RHEL-only Windows on Arm is a thing, and some of those machines support HYPERV. For WoA users it would be helpful if Fedora/etc ran well as a guest OS. The existing enablement patch fails to enable KEYBOARD_ATKB support needed for the hyperv_keyboard to function. That requires enabling the keyboard on ARK as well, so the config is synced a bit between fedora/ark sufficiently to get the correct kb drivers enabled in ARK. Signed-off-by: Jeremy Linton diff --git a/redhat/configs/ark/generic/arm/aarch64/CONFIG_INPUT_KEYBOARD b/redhat/configs/ark/generic/arm/aarch64/CONFIG_INPUT_KEYBOARD deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/ark/generic/arm/aarch64/CONFIG_INPUT_KEYBOARD +++ /dev/null @@ -1 +0,0 @@ -# CONFIG_INPUT_KEYBOARD is not set diff --git a/redhat/configs/fedora/generic/arm/CONFIG_INPUT_MATRIXKMAP b/redhat/configs/common/generic/arm/CONFIG_INPUT_MATRIXKMAP rename from redhat/configs/fedora/generic/arm/CONFIG_INPUT_MATRIXKMAP rename to redhat/configs/common/generic/arm/CONFIG_INPUT_MATRIXKMAP index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/arm/CONFIG_INPUT_MATRIXKMAP +++ b/redhat/configs/common/generic/arm/CONFIG_INPUT_MATRIXKMAP diff --git a/redhat/configs/fedora/generic/arm/CONFIG_KEYBOARD_TEGRA b/redhat/configs/common/generic/arm/CONFIG_KEYBOARD_TEGRA rename from redhat/configs/fedora/generic/arm/CONFIG_KEYBOARD_TEGRA rename to redhat/configs/common/generic/arm/CONFIG_KEYBOARD_TEGRA index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/arm/CONFIG_KEYBOARD_TEGRA +++ b/redhat/configs/common/generic/arm/CONFIG_KEYBOARD_TEGRA diff --git a/redhat/configs/common/generic/arm/aarch64/CONFIG_KEYBOARD_ATKBD b/redhat/configs/common/generic/arm/aarch64/CONFIG_KEYBOARD_ATKBD new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_KEYBOARD_ATKBD @@ -0,0 +1 @@ +CONFIG_KEYBOARD_ATKBD=y diff --git a/redhat/configs/common/generic/arm/aarch64/CONFIG_SERIO_LIBPS2 b/redhat/configs/common/generic/arm/aarch64/CONFIG_SERIO_LIBPS2 new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_SERIO_LIBPS2 @@ -0,0 +1 @@ +CONFIG_SERIO_LIBPS2=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1393 ___ 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/configs: Enable HYPERV host support on aarch64
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1393#note_772033418 I should have pushed to this MR, but I opened another one https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1525 which fixes the configs so that the hyperv_keyboard works. The configs by themselves still aren't sufficient to make hyperv work, I have another patch that does that for the existing win10/11 machines. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCH] redhat/configs: Fixup HYPERV config on aarch64
From: Jeremy Linton redhat/configs: Fixup HYPERV config on aarch64 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2007430 Upstream Status: RHEL-only Windows on Arm is a thing, and some of those machines support HYPERV. For WoA users it would be helpful if Fedora/etc ran well as a guest OS. The existing enablement patch fails to enable KEYBOARD_ATKB support needed for the hyperv_keyboard to function. That requires enabling the keyboard on ARK as well, so the config is synced a bit between fedora/ark sufficiently to get the correct kb drivers enabled in ARK. Signed-off-by: Jeremy Linton diff --git a/redhat/configs/ark/generic/arm/aarch64/CONFIG_INPUT_KEYBOARD b/redhat/configs/ark/generic/arm/aarch64/CONFIG_INPUT_KEYBOARD deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/ark/generic/arm/aarch64/CONFIG_INPUT_KEYBOARD +++ /dev/null @@ -1 +0,0 @@ -# CONFIG_INPUT_KEYBOARD is not set diff --git a/redhat/configs/fedora/generic/arm/CONFIG_INPUT_MATRIXKMAP b/redhat/configs/common/generic/arm/CONFIG_INPUT_MATRIXKMAP rename from redhat/configs/fedora/generic/arm/CONFIG_INPUT_MATRIXKMAP rename to redhat/configs/common/generic/arm/CONFIG_INPUT_MATRIXKMAP index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/arm/CONFIG_INPUT_MATRIXKMAP +++ b/redhat/configs/common/generic/arm/CONFIG_INPUT_MATRIXKMAP diff --git a/redhat/configs/fedora/generic/arm/CONFIG_KEYBOARD_TEGRA b/redhat/configs/common/generic/arm/CONFIG_KEYBOARD_TEGRA rename from redhat/configs/fedora/generic/arm/CONFIG_KEYBOARD_TEGRA rename to redhat/configs/common/generic/arm/CONFIG_KEYBOARD_TEGRA index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/arm/CONFIG_KEYBOARD_TEGRA +++ b/redhat/configs/common/generic/arm/CONFIG_KEYBOARD_TEGRA diff --git a/redhat/configs/common/generic/arm/aarch64/CONFIG_KEYBOARD_ATKBD b/redhat/configs/common/generic/arm/aarch64/CONFIG_KEYBOARD_ATKBD new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_KEYBOARD_ATKBD @@ -0,0 +1 @@ +CONFIG_KEYBOARD_ATKBD=y diff --git a/redhat/configs/common/generic/arm/aarch64/CONFIG_SERIO_LIBPS2 b/redhat/configs/common/generic/arm/aarch64/CONFIG_SERIO_LIBPS2 new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_SERIO_LIBPS2 @@ -0,0 +1 @@ +CONFIG_SERIO_LIBPS2=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1525 ___ 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/configs: enable CONFIG_BCMGENET as module
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1440#note_713822249 I can't ack config options, otherwise, I would :kiss_mm: So looks good to me! ___ 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/configs: Enable Hyper-V guests on ARM64
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1394#note_689579938 There is definitely a problem with the rodata checks, and for the moment the console/disk don't actually seem to be working correctly, so i'm digging into that 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] redhat/configs: Enable Hyper-V guests on ARM64
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1394#note_689519481 So, this look right and follows my other PR, but i'm curious what you're testing it on. I upgraded a lenovo 5g to win11 and am now experiencing early boot failures right before systemd in the initrd starts (Still pinning down the problem). ___ 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/configs: Enable HYPERV host support on aarch64
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1393#note_689518358 BTW: I haven't moved on this because I got my hands on a win11/lenovo 5g, and am having a boot problem with it now. So, i'm still debugging 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] redhat/configs: Enable HYPERV host support on aarch64
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1393#note_686695272 Ok, I thought it was for rc's, my bad. I will move that (and the MTE bits). ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCH] redhat/configs: Enable HYPERV host support on aarch64
From: Jeremy Linton redhat/configs: Enable HYPERV host support on aarch64 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2007430 Upstream Status: RHEL-only Windows on Arm is a thing, and some of those machines support HYPERV. For WoA users it would be helpful if Fedora/etc ran well as a guest OS. Signed-off-by: Jeremy Linton diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_DRM_HYPERV b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_DRM_HYPERV new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_DRM_HYPERV @@ -0,0 +1 @@ +CONFIG_DRM_HYPERV=m diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_FB_HYPERV b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_FB_HYPERV new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_FB_HYPERV @@ -0,0 +1 @@ +CONFIG_FB_HYPERV=m diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HID_HYPERV_MOUSE b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HID_HYPERV_MOUSE new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HID_HYPERV_MOUSE @@ -0,0 +1 @@ +CONFIG_HID_HYPERV_MOUSE=m diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV @@ -0,0 +1 @@ +CONFIG_HYPERV=y diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_BALLOON b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_BALLOON new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_BALLOON @@ -0,0 +1 @@ +CONFIG_HYPERV_BALLOON=m diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_IOMMU b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_IOMMU new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_IOMMU @@ -0,0 +1 @@ +CONFIG_HYPERV_IOMMU=y diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_KEYBOARD b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_KEYBOARD new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_KEYBOARD @@ -0,0 +1 @@ +CONFIG_HYPERV_KEYBOARD=m diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_NET b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_NET new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_NET @@ -0,0 +1 @@ +CONFIG_HYPERV_NET=m diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_STORAGE b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_STORAGE new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_STORAGE @@ -0,0 +1 @@ +CONFIG_HYPERV_STORAGE=m diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_UTILS b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_UTILS new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_UTILS @@ -0,0 +1 @@ +CONFIG_HYPERV_UTILS=m diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_VSOCKETS b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_VSOCKETS new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_HYPERV_VSOCKETS @@ -0,0 +1 @@ +CONFIG_HYPERV_VSOCKETS=m diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_UIO_HV_GENERIC b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_UIO_HV_GENERIC new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_UIO_HV_GENERIC @@ -0,0 +1 @@ +CONFIG_UIO_HV_GENERIC=m diff --git a/redhat/configs/pending-fedora/generic/arm/aarch64/CONFIG_DRM_HYPERV b/redhat/configs/pending-fedora/generic/arm/aarch64/CONFIG_DRM_HYPERV new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-fedora/generic/arm/aarch64/CONFIG_DRM_HYPERV @@ -0,0 +1 @@ +CONFIG_DRM_HYPERV=m diff --git a/redhat/configs/pending-fedora/generic/arm/aarch64/CONFIG_FB_HYPERV b/redhat/configs/pending-fedora/generic/arm/aarch64/CONFIG_FB_HYPERV new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/pending-fedora/generic/arm/aarch64
Re: [OS-BUILD PATCH] Use common config for NODES_SHIFT
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1333#note_674060479 Wierd this thing shows me a pile of unrelated commits because the rebase isn't clean? Anway +1 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH 0/0] Fedora: upstream fixes and enable rk3399 pcie drivers
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1176#note_604459685 I will give this a late, thumbs-up-by :) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv4 0/10] Arm ark/fedora config unification
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/884#note_524524247 I've been meaning to re-post that with proper CC's and the like, but have been off doing coresight stuff, which JCM just killed since marvell isn't around asking for it anymore. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv4 0/10] Arm ark/fedora config unification
From: Jeremy Linton on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/884 Enable some arm options globally across ark & fedora. Some of these options like coresight are already enabled in fedora and should be enabled in ark, are enabled=y and should be =m, or are the same (efi options) in both configs and should be moved into the common directory. general platform drivers, etc have been left alone. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv3 0/10] Arm ark/fedora config unification
From: Jeremy Linton on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/884 Enable some arm options globally across ark & fedora. Some of these options like coresight are already enabled in fedora and should be enabled in ark, are enabled=y and should be =m, or are the same (efi options) in both configs and should be moved into the common directory. general platform drivers, etc have been left alone. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCHv2 0/10] Arm ark/fedora config unification
From: Jeremy Linton on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/884 Enable some arm options globally across ark & fedora. Some of these options like coresight are already enabled in fedora and should be enabled in ark, are enabled=y and should be =m, or are the same (efi options) in both configs and should be moved into the common directory. general platform drivers, etc have been left alone. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCH 0/10] Arm ark/fedora config unification
From: Jeremy Linton on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/884 Enable some arm options globally across ark & fedora. Some of these options like coresight are already enabled in fedora and should be enabled in ark, are enabled=y and should be =m, or are the same (efi options) in both configs and should be moved into the common directory. general platform drivers, etc have been left alone. ___ 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 0/2] Enable coresight drives on aarch64, plus a couple trivial cleanups
From: Jeremy Linton on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/785#note_462666414 Yes, it probably should at some point. I'm not sure if that is now or at some point in the future, mostly because the centos test platform for ark doesn't have openocd yet. ___ 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
[PATCH] kernel: coresight: Enable coresight decoding
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: [PATCH 2/9] Drop cpumask auto select patch
Hi, On 8/22/19 11:36 AM, Laura Abbott wrote: On 8/22/19 8:58 AM, Prarit Bhargava wrote: On 8/19/19 9:15 AM, Laura Abbott wrote: On 8/16/19 2:57 PM, Paul Bolle wrote: Florian Weimer schreef op vr 16-08-2019 om 14:04 [+0200]: RHEL has a larger NR_CPU value, though. For example, it's 8192 on x86-64, while Fedora 31 has 1024. On the Fedora x86-64 debug builds it's 8192 again. Why's that? Paul Bolle That's the option for max cpus. We don't want to turn it on in all Fedora builds since it would use up more resources we probably don't actually need. Turning on for debugging in Fedora is okay though. RHEL is focused on larger footprints and makes the trade off to have it enabled all the time. I think I measured the impact of 8192 vs 512 (or 256?) a long time ago and we are talking about _k_ of memory. We should stick with what upstream has at 8192. It's easier to debug when we have the same value as the default IMO. Having said that, it has been a long time since I had to debug a NR_CPUS/nr_cpus issue in the kernel. We're just not seeing bugs around the value anymore. I was going to ask about the actual impact of a larger number of CPUs. If it's actually only k of memory it's probably better to just set MAXCPUS all the time. Even the lowest end machines probably see more change when frameworks change. And yes, I also think that we've come a long way so NR_CPUS is less of an important option to optimize these days. I think I'll just submit another patch to just do the max cpus. Forgive me if you have already posted (didn't see it yet). Its probably a good idea to bump the aarch64 config at the same time. Some aarch64 "desktop" machines is already at the 256 core limit currently in use. Thanks, Laura P. Thanks, Laura ___ 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
[PATCH] Sign the aarch64 kernel
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.
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
+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
[PATCH] mmc: dw_mmc-k3: Add clk and reset softdep
From: Jeremy Linton
The mmc/k3 driver is dependent on a number of other linux modules
which must be built into the initrd in order to use the mmc/sd
as a boot device for initrd/module based distros.
Normally this would be taken care of with linux's modules.deps
based on symbolic dependencies but the dwmmc drivers have
particularly complex relationships that are based on soft
callback APIs. The result is that dracut and other initrd builders
are unable to determine the module dependencies directly.
To solve this problem linux has MODULE_SOFTDEP() so lets softdep
the hisi clock and reset drivers associated with the k3 implementation.
Signed-off-by: Jeremy Linton
---
drivers/mmc/host/dw_mmc-k3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c
index 89cdb3d533bb..cd8f545fa30d 100644
--- a/drivers/mmc/host/dw_mmc-k3.c
+++ b/drivers/mmc/host/dw_mmc-k3.c
@@ -487,3 +487,4 @@ module_platform_driver(dw_mci_k3_pltfm_driver);
MODULE_DESCRIPTION("K3 Specific DW-MSHC Driver Extension");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("platform:dwmmc_k3");
+MODULE_SOFTDEP("pre: hi6220_reset clk_hi655x");
--
2.13.6
___
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
adv7511, hikey and commit 8221dd34f
Hi, It seems that commit 8221dd34f turned off CONFIG_DRM_I2C_ADV7511. That is the HDMI transmitter used on the 96boards hikey. The result is that the framebuffer no longer works.. Can we get that config option enabled for just aarch64? (I can submit a bug/patch/whatever if that is easier than this bug report). Thanks, ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Re: [PATCH] arm64: Enable 48bit VA
Hi, On 10/28/2016 03:29 PM, Jeremy Linton wrote: The existing 42-bit VA used in fedora is quite limiting. Lets turn on 48-bit VA's now that the core mozjs/polkit fixes are in place. In case it wasn't clear should have tagged this for rawhide/F26.. If anyone would like to test it, there is a week+ old koji build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=16154370 Thanks, Signed-off-by: Jeremy Linton --- config-arm64 | 3 +++ 1 file changed, 3 insertions(+) diff --git a/config-arm64 b/config-arm64 index 4156910..15027e3 100644 --- a/config-arm64 +++ b/config-arm64 @@ -1,6 +1,9 @@ CONFIG_64BIT=y CONFIG_ARM64=y +CONFIG_ARM64_VA_BITS_48=y +CONFIG_ARM64_VA_BITS=48 + # arm64 only SoCs CONFIG_ARCH_HISI=y CONFIG_ARCH_QCOM=y ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
[PATCH] arm64: Enable 48bit VA
The existing 42-bit VA used in fedora is quite limiting. Lets turn on 48-bit VA's now that the core mozjs/polkit fixes are in place. Signed-off-by: Jeremy Linton --- config-arm64 | 3 +++ 1 file changed, 3 insertions(+) diff --git a/config-arm64 b/config-arm64 index 4156910..15027e3 100644 --- a/config-arm64 +++ b/config-arm64 @@ -1,6 +1,9 @@ CONFIG_64BIT=y CONFIG_ARM64=y +CONFIG_ARM64_VA_BITS_48=y +CONFIG_ARM64_VA_BITS=48 + # arm64 only SoCs CONFIG_ARCH_HISI=y CONFIG_ARCH_QCOM=y -- 2.5.5 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Re: [PATCH] config: arm64: Enable generic PCI host bridge
On 05/13/2016 12:41 PM, Josh Boyer wrote: On Thu, May 12, 2016 at 4:42 PM, Jeremy Linton wrote: On 05/12/2016 02:59 PM, Peter Robinson wrote: The ARM Juno development platform's PCIe is supported by the generic PCI host driver. Enable it so that PCIe attached peripherals work. Pushed as (F-24 and rawhide) http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/?h=f24&id=decdd1f9105004f6e2ca24cc85bffcf6efb82d28 Let me know if there's other branches you'd like it on, also let me know if there's other improvements that can be made for Juno, we've not had anyone to test so what we have is a bit of a guess so any feedback for Juno support would be useful. Thanks those two branches should be sufficient. I have a few other tweaks to post now that I seem to have cleared some internal hurtles. Excellent, really glad to get confirmation it's looking reasonable. FYI: There is a dmi_match oops on boot, and the SMSC's phy state change isn't consistently detected, resulting in unreliable link detection. Plus, there is likely a grub EFI issue (there are a couple bugs floating around about that). 1) dmi_match oops we've seen for a long time, it doesn't seem to cause issues but I think it's because most devices don't actually have dmi tables (or what ever they're called) so should likely be taught to behave on absence This machine has DMI tables, the problem is that the fedora specific watchdog-Disable-watchdog-on-virtual-machines.patch is making calls to dmi_check_system before the smbios initcall has set up the tables (AFAIK). When is that initcall done on your platform? lockup_detector_init is called in a kthread started by the rest_init function. All of that is called after acpi_subsystem_init, sfi_init_late, efi_late_init, and efi_free_boot_services. Also, the dmi code protects itself behind the dmi_initialized variable, so if dmi_check_system is called before dmi_scan_machine is called then nothing bad should happen. On x86, dmi_scan_machine is called from setup_arch, which is well before any of the above functions are called. Its the WARN(!dmi_initialized, KERN_ERR "dmi check: not initialized yet.\n"); in dmi_matches that is firing. That is because, arm64_dmi_init is a core_initcall() and ends up being called after the watchdog/SMP setup, same on IA64 the only other platform with a dmi_scan_machine() call. A large part of this is because it should run after arm_enable_runtime_services, which is an early_initcall itself. I moved the arm64_dmi_init() call into arm_enable_runtime_services() and removed the core_initcall(arm64_dmi_init) and that solves the problem. Of course that will likely cause a build failure on 32-bit ARM without some kind of stubbed out call. ___ kernel mailing list kernel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org
Re: [PATCH] config: arm64: Enable generic PCI host bridge
On 05/12/2016 02:59 PM, Peter Robinson wrote: The ARM Juno development platform's PCIe is supported by the generic PCI host driver. Enable it so that PCIe attached peripherals work. Pushed as (F-24 and rawhide) http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/?h=f24&id=decdd1f9105004f6e2ca24cc85bffcf6efb82d28 Let me know if there's other branches you'd like it on, also let me know if there's other improvements that can be made for Juno, we've not had anyone to test so what we have is a bit of a guess so any feedback for Juno support would be useful. Thanks those two branches should be sufficient. I have a few other tweaks to post now that I seem to have cleared some internal hurtles. Excellent, really glad to get confirmation it's looking reasonable. FYI: There is a dmi_match oops on boot, and the SMSC's phy state change isn't consistently detected, resulting in unreliable link detection. Plus, there is likely a grub EFI issue (there are a couple bugs floating around about that). 1) dmi_match oops we've seen for a long time, it doesn't seem to cause issues but I think it's because most devices don't actually have dmi tables (or what ever they're called) so should likely be taught to behave on absence This machine has DMI tables, the problem is that the fedora specific watchdog-Disable-watchdog-on-virtual-machines.patch is making calls to dmi_check_system before the smbios initcall has set up the tables (AFAIK). 2) Is SMSC the standard usb attached device or something else? Juno has two Ethernet controllers, a memory mapped 10/100 smc911x that is described by DT/ACPI, and a PCIe attached 1Gb marvell sky2. Out of the box, nothing is attached to the usb/ehci controller. ___ kernel mailing list kernel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org
Re: [PATCH] config: arm64: Enable generic PCI host bridge
On 05/12/2016 12:10 PM, Peter Robinson wrote: On Thu, May 12, 2016 at 5:24 PM, Jeremy Linton wrote: The ARM Juno development platform's PCIe is supported by the generic PCI host driver. Enable it so that PCIe attached peripherals work. Pushed as (F-24 and rawhide) http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/?h=f24&id=decdd1f9105004f6e2ca24cc85bffcf6efb82d28 Let me know if there's other branches you'd like it on, also let me know if there's other improvements that can be made for Juno, we've not had anyone to test so what we have is a bit of a guess so any feedback for Juno support would be useful. Thanks those two branches should be sufficient. I have a few other tweaks to post now that I seem to have cleared some internal hurtles. FYI: There is a dmi_match oops on boot, and the SMSC's phy state change isn't consistently detected, resulting in unreliable link detection. Plus, there is likely a grub EFI issue (there are a couple bugs floating around about that). Other than that, it seems to be mostly working (given the PCIe tweak). Its also somewhat functional in ACPI mode if you don't mind not having any PCIe... ___ kernel mailing list kernel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org
[PATCH] config: arm64: Enable generic PCI host bridge
The ARM Juno development platform's PCIe is supported by the generic PCI host driver. Enable it so that PCIe attached peripherals work. Signed-off-by: Jeremy Linton --- config-arm64 | 3 +++ 1 file changed, 3 insertions(+) diff --git a/config-arm64 b/config-arm64 index 77dde02..2db4e9a 100644 --- a/config-arm64 +++ b/config-arm64 @@ -110,6 +110,9 @@ CONFIG_CRYPTO_DEV_CCP=y CONFIG_CRYPTO_DEV_CCP_DD=m CONFIG_CRYPTO_DEV_CCP_CRYPTO=m +# ARM Juno +CONFIG_PCI_HOST_GENERIC=y + # APM Xgene CONFIG_POWER_RESET_XGENE=y CONFIG_COMMON_CLK_XGENE=y -- 2.5.5 ___ kernel mailing list kernel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org
