Re: [PATCH 9/9] kernel/x86: remove DRM support
> Le 29 avr. 2023 à 05:45, Elliott Mitchell a écrit : > > On Thu, Apr 27, 2023 at 11:21:28AM +0200, Thibaut wrote: >> >>> Le 27 avr. 2023 à 02:11, Elliott Mitchell a écrit : >>> […] >> You seem to assume that x86 is only/mainly run on VMs. >> That is not necessarily the case, and I see no reason to degrade device >> support that way. > > Okay, as already stated there are at least two solutions to this. > > 1> Turn most functionality into modules and include support for runtime > loading of kernel modules. > > 2> Create more kernel variants for OpenWRT/x86. 3> leave things as they are. The current setup supports a very large scope of hardware and virtualizations with minimal fuss, and will happily run with 128M RAM with Luci enabled (I just tested that with 22.03.4 x86/64 stock image in a 128M RAM VM: after boot it had 64M free). Maybe this info could be added to the x86 wiki page. It’s likely it could even be convinced to run with 64M only if you really needed(?) that, which is the current lowest recommandation across all OpenWrt targets. So it seems to me you’re trying to fix a problem that isn’t there. As pointed out by Felix, if you need something highly tailored it’s easy to achieve as well. HTH T ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/9] (mostly) x86 kernel configuration adjustments
On 29.04.23 02:50, Elliott Mitchell wrote: On Thu, Apr 27, 2023 at 05:38:18AM +0200, Stefan Lippers-Hollmann wrote: On 2023-04-26, Elliott Mitchell wrote: > On Thu, Apr 27, 2023 at 01:11:13AM +0200, Stefan Lippers-Hollmann wrote: > > On 2023-04-26, Elliott Mitchell wrote: > > [...] > > > > > > Looks like little of ISA remained on "64", yet some DMA support remained > > > due to the generic configuration. Remove the ISA and ISA DMA support > > > from the top-level configuration. Geode and Legacy though almost > > > certainly still need ISA support. > > > > You might find that while ISA went away as an addon slot quite quickly, > > it still survived rather long for low performance onboard devices (e.g. > > sensors). > > I know, I was unsure of when it 100% disappeared. Do you expect anything > besides "legacy" to be used for this type of system though? [...] Ignoring industrial PCs (where you may still encounter ISA today), you'd have to venture into the pre-LPC days (and AMD, VIA, nVidia might have gone with ISA beyond that) - which might get you into the 2005-2009 time frame (anything with an onboard floppy controller might be worth looking at - and those were still around into the LGA755/ core2 (x86_64) days - in that particular case probably LPC based though). Perhaps have "64" and "old64" (or "early64") then? Seems rather a lot of legacy disappeared between 2005 and 2010. FDC, ISA, PATA and AGP were all common in 2005, yet by 2010 they were non-existant. If you need a build for yourself with a specialized stripped down kernel config, there is an easy (and reasonably maintainable) approach to doing so. First you need to use this: https://openwrt.org/docs/guide-developer/toolchain/env Create an env for your main config. Afterwards, you can run: make kernel_menuconfig CONFIG_TARGET=env Any change you make there will be stored in env/kernel-config, which is an overlay that is applied on top of the target config. You can use it to disable any features you like without having to modify any files in the OpenWrt source directory, and it should continue to work with pretty much any source tree updates. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Regression in backport MEMREAD ioctl ? [Was: Re: mt7622: belkin-rt3200: r22602-42eeb22450: Kernel panic: kernel stack overflow]
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
> > https://github.com/openwrt/openwrt/pull/12472
>
> thanks a lot for your attempt, but unfortunately it didn't fixed the issue.
>
> I've tried to revert commit fa4dc86 ("kernel: backport MEMREAD ioctl") and
> that fixed the issue as Felix already hinted.
Just to close the loop here: a different fix has been prepared that
replaces recursion with iteration in the mtk_bmt driver:
https://github.com/openwrt/openwrt/pull/12494
This revised fix appears to be working:
https://github.com/openwrt/openwrt/pull/12472#issuecomment-1525636591
--
Best regards,
Michał Kępień
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/9] kernel: change CONFIG_HW_RANDOM default to y
On Fri, Apr 28, 2023 at 10:29:29AM -0600, Philip Prindeville wrote: > Why isn't this migrating upwards into target/linux/generic/config-5.15 and > target/linux/generic/config-5.10 in that case? > > And for the platforms where it was turned off, like > target/linux/armvirt/32/config-5.15, why isn't that staying unchanged? I'm guessing you're unaware of a subtlety of how the .config system actually works. Take a second look, some handy examples: > > On Apr 22, 2023, at 11:46 AM, Elliott Mitchell wrote: > > diff --git a/target/linux/armvirt/32/config-5.10 > > b/target/linux/armvirt/32/config-5.10 > > index 3c6443bcbf..2f7cd03b5f 100644 > > --- a/target/linux/armvirt/32/config-5.10 > > +++ b/target/linux/armvirt/32/config-5.10 > > @@ -47,6 +47,7 @@ CONFIG_EDAC_ATOMIC_SCRUB=y > > CONFIG_GENERIC_VDSO_32=y > > CONFIG_HARDEN_BRANCH_PREDICTOR=y > > CONFIG_HAVE_SMP=y > > +CONFIG_HW_RANDOM=n > > CONFIG_HZ_FIXED=0 > > CONFIG_HZ_PERIODIC=y > > CONFIG_MIGHT_HAVE_CACHE_L2X0=y > > diff --git a/target/linux/armvirt/32/config-5.15 > > b/target/linux/armvirt/32/config-5.15 > > index bf6e2a5cde..bb2a7a320f 100644 > > --- a/target/linux/armvirt/32/config-5.15 > > +++ b/target/linux/armvirt/32/config-5.15 > > @@ -49,6 +49,7 @@ CONFIG_GENERIC_IRQ_MULTI_HANDLER=y > > CONFIG_GENERIC_VDSO_32=y > > CONFIG_HARDEN_BRANCH_PREDICTOR=y > > CONFIG_HAVE_SMP=y > > +CONFIG_HW_RANDOM=n > > CONFIG_HZ_FIXED=0 > > CONFIG_HZ_PERIODIC=y > > CONFIG_MIGHT_HAVE_CACHE_L2X0=y > > diff --git a/target/linux/armvirt/64/config-5.10 > > b/target/linux/armvirt/64/config-5.10 > > index 275fe4571d..af46939ad2 100644 > > --- a/target/linux/armvirt/64/config-5.10 > > +++ b/target/linux/armvirt/64/config-5.10 > > @@ -102,7 +102,6 @@ CONFIG_GPIO_GENERIC=y > > CONFIG_GPIO_GENERIC_PLATFORM=y > > CONFIG_HDMI=y > > CONFIG_HOLES_IN_ZONE=y > > -CONFIG_HW_RANDOM=y > > CONFIG_HW_RANDOM_VIRTIO=y > > CONFIG_I2C=y > > CONFIG_I2C_ALGOBIT=y > > diff --git a/target/linux/armvirt/64/config-5.15 > > b/target/linux/armvirt/64/config-5.15 > > index 19ae3dc0cf..88f2f64cde 100644 > > --- a/target/linux/armvirt/64/config-5.15 > > +++ b/target/linux/armvirt/64/config-5.15 > > @@ -103,7 +103,6 @@ CONFIG_GENERIC_FIND_FIRST_BIT=y > > CONFIG_GPIO_GENERIC=y > > CONFIG_GPIO_GENERIC_PLATFORM=y > > CONFIG_HDMI=y > > -CONFIG_HW_RANDOM=y > > CONFIG_HW_RANDOM_ARM_SMCCC_TRNG=y > > CONFIG_HW_RANDOM_VIRTIO=y > > CONFIG_I2C=y > > diff --git a/target/linux/ath25/config-5.10 b/target/linux/ath25/config-5.10 > > index ef764820e4..41e65c72ad 100644 > > diff --git a/target/linux/generic/config-5.10 > > b/target/linux/generic/config-5.10 > > index f6f1fb0278..853c13852d 100644 > > --- a/target/linux/generic/config-5.10 > > +++ b/target/linux/generic/config-5.10 > > @@ -2343,7 +2343,7 @@ CONFIG_HPET_MMAP_DEFAULT=y > > # CONFIG_HWSPINLOCK is not set > > # CONFIG_HWSPINLOCK_OMAP is not set > > CONFIG_HW_PERF_EVENTS=y > > -# CONFIG_HW_RANDOM is not set > > +CONFIG_HW_RANDOM=y > > # CONFIG_HW_RANDOM_AMD is not set > > # CONFIG_HW_RANDOM_ATMEL is not set > > # CONFIG_HW_RANDOM_BA431 is not set > > diff --git a/target/linux/generic/config-5.15 > > b/target/linux/generic/config-5.15 > > index ac75a480a1..bf38732b31 100644 > > --- a/target/linux/generic/config-5.15 > > +++ b/target/linux/generic/config-5.15 > > @@ -2444,7 +2444,7 @@ CONFIG_HPET_MMAP_DEFAULT=y > > # CONFIG_HWSPINLOCK is not set > > # CONFIG_HWSPINLOCK_OMAP is not set > > CONFIG_HW_PERF_EVENTS=y > > -# CONFIG_HW_RANDOM is not set > > +CONFIG_HW_RANDOM=y > > # CONFIG_HW_RANDOM_AMD is not set > > # CONFIG_HW_RANDOM_ARM_SMCCC_TRNG is not set > > # CONFIG_HW_RANDOM_ATMEL is not set armvirt/32 previously had it off and it is still off. armvirt/64 previously had it on and it is still on. Most similar systems would treat "# is not set" as undefined or no preference (use the default value). The Linux kernel system treats this as "no" due to the history of the system. Yet it also honors "n" as "no". I tend to prefer "n" as it hints at a value being deliberately chosen, instead of being left unset/undefined. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
