Re: [PATCH] m68k: Define NR_CPUS to 1
Uwe Kleine-König <[email protected]> Mon, 3 Aug 2026 10:56:38 +0200
| Newsgroups | org.kernel.vger.linux-m68k,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <anBXIAqwllKX-Sxx@monoceros> |
--4xm5bakmko2rqbza Content-Type: text/plain; protected-headers=v1; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH] m68k: Define NR_CPUS to 1 MIME-Version: 1.0 On Mon, Aug 03, 2026 at 09:58:14AM +0200, Geert Uytterhoeven wrote: > Hi Uwe, >=20 > Thanks for your patch! >=20 > On Fri, 31 Jul 2026 at 11:50, Uwe Kleine-K=F6nig <[email protected]> wr= ote: > > This fixes a Kconfig warning > > > > fs/erofs/Kconfig:137:warning: range is invalid > > > > which originates from EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS using > > NR_CPUS which up to now didn't exist for ARCH=3Dm68k. All other > > architectures define this symbol, so fix the outlier. >=20 > Apart from the Kconfig warning, this also > 1. Breaks pressing "ENTER" in "make oldconfig" to apply a sensible > default value, just repeating the question ad infinitum instead > (the default is 16), > 2. "make olddefconfig" sets it to literal NR_CPUS, which is invalid, to= o. >=20 > > Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size") > > Signed-off-by: Uwe Kleine-K=F6nig <[email protected]> >=20 > > --- a/arch/m68k/Kconfig.cpu > > +++ b/arch/m68k/Kconfig.cpu > > @@ -549,6 +549,10 @@ config CACHE_COPYBACK > > endchoice > > endif # HAVE_CACHE_CB > > > > +config NR_CPUS > > + int > > + default "1" >=20 > While this does fix the issues on m68k, I don't think this is the > right fix: > - NR_CPUS depends on SMP on most architectures, so you do not get > the "range is invalid" warning on non-SMP, but NR_CPUS is zero. > Hence I managed to reproduce the two issues above (albeit 2 with > CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=3D0) with a non-SMP > ARM config. > - Kconfig logic using NR_CPUS typically includes a check for SMP, too. >=20 > So I think EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS should be fixed > instead. Agreed, probably it should depend on SMP, too. Thanks for your feedback Uwe --4xm5bakmko2rqbza Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmpwV7kACgkQj4D7WH0S /k4trwgAkwblevNimVZBgYfsHYEmsQ0zcz8tpUcW2SdiHTgqxgbfG3JUfNGhuXkC 8eZMDfl2hSuERqhKbfUyU4pccEpjYSwwFMe26wyAcQKpDwkaONjbHdA3nBbVuxy5 lVj1YOp469FEwhMxGWEEjrjaKOZSMOoR3Xi59YNKCtxlwJbUxnVxui+BRsohuvE0 bnGWDs8Dc5phlheHkuI8SnCsNVboufj4BqY9nQ8iOmNroQylrMbYKL9S4CMjHkeV dgOsb/MZErv5hKtUxqUrsDZ7ouy+a/A9gL65+HucXP63pVWIDq+QIZE+Ctq8NHod C1v2kh4VDQwzXZ0xEBicynvHFbjUww== =TiFt -----END PGP SIGNATURE----- --4xm5bakmko2rqbza--