Re: [PATCH] Kconfig: purge twenty-nine legacy ghost options

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Sep 04, 2026 at 08:12:40PM -0300, Breno Rodrigues Alves wrote:
> You can keep a dead config option around for a while out of sympathy.
> After a couple of releases it stops being "transitional" and starts
> being "you are confusing every user who greps for it". These options
> select nothing, gate nothing, and -- I checked by hand, this is not a
> regex accident -- are referenced by exactly nobody in the tree.
> 
> Evidence for each removal:
>   * no CONFIG_<sym> reference outside the Kconfig definition itself
>   * no <sym> reference as an 'if'/'select'/'depends on' target
>   * no mention in any defconfig, any Documentation, or any source build
>   * the code they used to gate is gone (removed or folded into a real
>     driver that already has its own, functioning config symbol)
> 
> Headliners of the graveyard:
>   - HID_THINGM: help text literally said "will be removed soon". Well.
>     Gone now. The blink(1) driver is HJID_LED.
>   - USB_CONFIGFS_F_TCM: the real fabric always built via USB_F_TCM; the
>     "CONFIGFS" name was a leftover from when someone could not decide
>     what to call the thing.
>   - USB_EHCI_TEGRA, USB_OCTEON_OHCI, USB_OHCI_HCD_SSB: help text says
>     "driver was removed, use X instead". The other X already exists.
>   - PANEL: proudly labeled "OLD OPTION" with its own "Deprecated
>     options" section in the file. The actual parport lcd driver has
>     always been PARPORT_PANEL.
>   - COMMON_CLK_MT6765_*: seven sysclk entries with no matching object
>     in the Makefile. Zero files built, zero regrets.
>   - The usual kconfig-vandalism suspects (HAVE_PWRCTL, REGULATOR_MT6316,
>     INTERCONNECT_MTK_MT8196, CLK_SUNXI_PRCM_SUN9I, DVB_ULE_DEBUG, ...).
> 
> Validated: defconfig, olddefconfig and randconfig parse clean on both
> x86_64 and arm64; headers_install (the target that replaced the dearly
> departed headers_check, which this tree does not have) succeeds with a
> clean UAPI on both architectures. Because someone will ask: yes, I
> checked the s390/arm/riscv No, I did not delete any arch/* Kconfig, and
> no, I did not touch a single include/uapi/ file.
> 
> Why should you care? Because "make menuconfig" allegedly lets people
> configure the kernel, and leaving a menu full of options that do
> nothing makes them feel like they have a choice when they really are
> just being sold snake oil. Clean it up.
> 
> Signed-off-by: Breno Rodrigues Alves <breno3011alves@gmail.com>

Did you forget the Assisted-by: tag here?

ANd this should be broken up per subsystem please.

thanks,

greg k-h