[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20211216150347.GB15172@alpha.franken.de>
Date: Thu, 16 Dec 2021 16:03:47 +0100
From: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To: Lukas Bulwahn <lukas.bulwahn@...il.com>
Cc: linux-mips@...r.kernel.org, kernel-janitors@...r.kernel.org,
linux-kernel@...r.kernel.org,
"Maciej W . Rozycki" <macro@...am.me.uk>,
Sander Vanheule <sander@...nheule.net>,
Bert Vermeulen <bert@...t.com>,
Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
Serge Semin <Sergey.Semin@...kalelectronics.ru>,
Paul Burton <paulburton@...nel.org>,
Daniel Silsby <dansilsby@...il.com>,
Paul Cercueil <paul@...pouillou.net>
Subject: Re: [PATCH 0/9] Kconfig symbol clean-up on ./arch/mips/
On Mon, Dec 13, 2021 at 12:16:33PM +0100, Lukas Bulwahn wrote:
> Dear Thomas,
>
> The script ./scripts/checkkconfigsymbols.py warns on invalid references to
> Kconfig symbols (often, minor typos, name confusions or outdated references).
> This is a patch series addressing the issues reported by
> ./scripts/checkkconfigsymbols.py in the ./arch/mips/ directory, quickly
> filtered down with:
>
> ./scripts/checkkconfigsymbols.py | grep "arch/mips" -B 1
>
> without considering kernel configs, i.e., after removing ./arch/mips/configs
> in the working tree. It addresses all issues I considered to be "true
> positives"; so, issues that should be addressed and cleaned up.
>
> The patches on updating the comments might arguably be considered of lower
> value by itself, but as the other patches show, checkkconfigsymbols does detect
> some relevant issues in the kernel tree otherwise being unnoticed.
> So, it might be worth to clean up the kernel tree to have checkkconfigsymbols
> produce a rather short list of issues and then continuously follow and check
> what checkkconfigsymbols reports.
>
> These are the remaining reports from checkkconfigsymbols in ./arch/mips, which
> are not addressed in this series:
>
> SGI_IP35
> Referencing files: arch/mips/include/asm/sn/addrs.h, arch/mips/include/asm/sn/agent.h, arch/mips/include/asm/sn/klconfig.h
>
> Rationale: Ralf Baechle rejected a patch to remove the "upstream-dead"
> SGI_IP35 code in 2014, because there was still some out-of-tree users.
> We might want to recheck if these out-of-tree users still exist or if this
> code can be dropped now.
> See email discussion: https://lore.kernel.org/lkml/1400584909.4912.35.camel@x220/T/#mf1d73d4f531bab670beb30aa0adfce34cbcad528
>
> SHELL
> Referencing files: arch/mips/Makefile, arch/mips/kernel/syscalls/Makefile
>
> Rationale: Ignore CONFIG_SHELL. Default variable in Kbuild build system.
>
>
> Each patch in this series can be discussed and applied individually. They are
> sent in one patch series, as they all orginate from the investigation guided
> by the same tool and hence share similar topics and resolutions.
>
> Please pick this series of minor clean-up patches on ./arch/mips/. It applies
> cleanly on next-20211210. The patches with Fixes: tags might be considerable
> for stable.
>
>
> Best regards,
>
> Lukas
>
>
> Lukas Bulwahn (9):
> mips: drop selecting the non-existing config SYS_HAS_EARLY_PRINTK_8250
> mips: add SYS_HAS_CPU_MIPS64_R5 config for MIPS Release 5 support
> mips: drop selecting non-existing config NR_CPUS_DEFAULT_2
> mips: dec: provide the correctly capitalized config CPU_R4X00 in init
> error message
> mips: kgdb: adjust the comment to the actual ifdef condition
> mips: remove obsolete selection of CPU_HAS_LOAD_STORE_LR
> mips: alchemy: remove historic comment on gpio build constraints
> mips: txx9: remove left-over for removed TXX9_ACLC configs
> mips: fix Kconfig reference to PHYS_ADDR_T_64BIT
>
> arch/mips/Kconfig | 9 +++++----
> arch/mips/alchemy/common/gpiolib.c | 2 --
> arch/mips/dec/prom/init.c | 2 +-
> arch/mips/include/asm/kgdb.h | 2 +-
> arch/mips/txx9/Kconfig | 3 ---
> arch/mips/txx9/generic/setup.c | 28 ----------------------------
> 6 files changed, 7 insertions(+), 39 deletions(-)
>
> --
> 2.26.2
applied patches 2-8 to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
Powered by blists - more mailing lists