[RFC v1] tree-wide: remove "select FW_LOADER" uses

[RFC v1] tree-wide: remove "select FW_LOADER" uses

[Luis R. Rodriguez]

There are some some recursive dependency issues one can run into
when a kconfig option is selected by a driver, and then kconfig
has to figure out whether or not some dependencies are valid for
that selected option. For instance in terms of simplifying the
logic issue a best as possible on my part and its implications:

  If a driver selects FW_LOADER but also has a few other selects,
  kconfig will not allow another driver which also selects FW_LOADER
  to negate dependency on what that original driver's extra
  dependencies were.

This was recenlty discovered while working on extensions to the
firmware_class module with some code being developed [0] to make
firmware_class APIs extensible.

A possible fix to this is to change a "select FW_LOADER" to
"depends FW_LOADER".  If we're going to do that we would first
need to evaluate if the recursive dependency issue is real or
not, and if it is not we should do a tree wide change from
all "select FW_LOADER" to "depend FW_LOADER".

Upon review with Paul, the recursive dependency issue is actually
real mostly because of the complexity of the amount of symbols
we handle and how we ended up deciding in logic for "select" and
"depends on" to work [1].

Paul did some git archaeological analysis of previous trends on
gramatically similar reported recursive issues and found that
the generic solution to such problems were to convert "select FOO"
to "depends on FOO". This was based on a study of 20 commits with
similar reported recursive issue reported since v2.6.36 [2].

Paul also found commit d9b19199e489 ("always enable FW_LOADER unless
EMBEDDED=y") which explains that we can then get rid of all
"select FW_LOADER" [...] and as per Paul it seems the plan to get rid
of those never materialized [2].

Paul also insists that *there is no reason* to think that current logic
of the kconfig tools, as it is currently implemented, is flawed [2].

The above history is just *one* set of reasons to remove all kernel
"select FW_LOADER" entries. Another simple reason is that since
FW_LOADER can only be disabled by an EXPERT and it defaults to y
its now a superfluous select. We will ensure things build for you
if using EXPERT but if you have selected EXPERT you should know
what run time requirements you need.

This goes build tested with an allyesconfig and allmodconfig
configuration and then disabling FW_LOADER on each build target.
This was tested on linux-next tag next-20150518.

Should this require rebasing you can regenerate the target
patches with:

for i in $(git grep "select FW_LOADER$" | \
	   awk -F":" '{print $1}' | sort | uniq); do \
	perl -i -ne 'print if !/select FW_LOADER$/' $i; done

[0] https://lkml.org/lkml/2015/5/7/814
[1] https://lkml.org/lkml/2015/5/8/748
[2] https://lkml.org/lkml/2015/5/18/835

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---

I realize tree-wide changes are not encourated like this, but
I am doing this as an RFC first to save a few electrons to
spare sending out 21 separate e-mails and separate reviews
and discussions on one topic alone, should there be any. If
this seems reasonable please send me your respective Acked-by's,
and I can split up into 21 patches by subsystem:

network
media
sound
scsi
drm
input
dell_rbu
crypto
bluetooth
leds
atm
staging
usb
tty
uwb
misc
pcmcia
remoteproc
arm mach-ixp4xx
cris
x86 microcode

If you wish me to just merge a bunch of these together let me
know as well.

 arch/arm/mach-ixp4xx/Kconfig              |  1 -
 arch/cris/arch-v32/drivers/Kconfig        |  1 -
 arch/x86/Kconfig                          |  3 ---
 drivers/atm/Kconfig                       |  2 --
 drivers/bluetooth/Kconfig                 |  7 -------
 drivers/crypto/qat/Kconfig                |  1 -
 drivers/firmware/Kconfig                  |  1 -
 drivers/gpu/drm/Kconfig                   |  3 ---
 drivers/gpu/drm/nouveau/Kconfig           |  1 -
 drivers/input/touchscreen/Kconfig         |  1 -
 drivers/leds/Kconfig                      |  1 -
 drivers/media/dvb-frontends/Kconfig       |  1 -
 drivers/media/pci/saa7164/Kconfig         |  1 -
 drivers/media/platform/exynos4-is/Kconfig |  1 -
 drivers/media/radio/Kconfig               |  1 -
 drivers/media/usb/as102/Kconfig           |  1 -
 drivers/misc/Kconfig                      |  1 -
 drivers/misc/ti-st/Kconfig                |  1 -
 drivers/net/ethernet/broadcom/Kconfig     |  2 --
 drivers/net/ethernet/chelsio/Kconfig      |  2 --
 drivers/net/ethernet/myricom/Kconfig      |  1 -
 drivers/net/ethernet/qlogic/Kconfig       |  2 --
 drivers/net/ethernet/realtek/Kconfig      |  1 -
 drivers/net/ethernet/toshiba/Kconfig      |  1 -
 drivers/net/irda/Kconfig                  |  1 -
 drivers/net/wimax/i2400m/Kconfig          |  1 -
 drivers/net/wireless/Kconfig              |  6 ------
 drivers/net/wireless/ath/ar5523/Kconfig   |  1 -
 drivers/net/wireless/ath/carl9170/Kconfig |  1 -
 drivers/net/wireless/b43/Kconfig          |  1 -
 drivers/net/wireless/b43legacy/Kconfig    |  1 -
 drivers/net/wireless/brcm80211/Kconfig    |  4 ----
 drivers/net/wireless/ipw2x00/Kconfig      |  2 --
 drivers/net/wireless/iwlegacy/Kconfig     |  1 -
 drivers/net/wireless/iwlwifi/Kconfig      |  1 -
 drivers/net/wireless/libertas/Kconfig     |  1 -
 drivers/net/wireless/mwifiex/Kconfig      |  3 ---
 drivers/net/wireless/orinoco/Kconfig      |  2 --
 drivers/net/wireless/p54/Kconfig          |  1 -
 drivers/net/wireless/rt2x00/Kconfig       |  1 -
 drivers/net/wireless/rtlwifi/Kconfig      |  1 -
 drivers/net/wireless/ti/wl1251/Kconfig    |  1 -
 drivers/net/wireless/ti/wlcore/Kconfig    |  1 -
 drivers/net/wireless/zd1211rw/Kconfig     |  1 -
 drivers/pcmcia/Kconfig                    |  1 -
 drivers/remoteproc/Kconfig                |  1 -
 drivers/scsi/Kconfig                      |  1 -
 drivers/scsi/aic94xx/Kconfig              |  1 -
 drivers/scsi/csiostor/Kconfig             |  1 -
 drivers/scsi/mvsas/Kconfig                |  1 -
 drivers/scsi/qla2xxx/Kconfig              |  1 -
 drivers/staging/rtl8192e/rtl8192e/Kconfig |  1 -
 drivers/staging/rtl8712/Kconfig           |  1 -
 drivers/staging/vt6656/Kconfig            |  1 -
 drivers/tty/Kconfig                       |  3 ---
 drivers/tty/serial/Kconfig                |  2 --
 drivers/usb/atm/Kconfig                   |  3 ---
 drivers/usb/misc/Kconfig                  |  1 -
 drivers/uwb/Kconfig                       |  1 -
 sound/drivers/Kconfig                     |  1 -
 sound/isa/Kconfig                         |  5 -----
 sound/pci/Kconfig                         | 21 ---------------------
 sound/pci/hda/Kconfig                     |  2 --
 sound/soc/sh/Kconfig                      |  1 -
 sound/usb/Kconfig                         |  1 -
 65 files changed, 121 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/Kconfig b/arch/arm/mach-ixp4xx/Kconfig
index c342dc4..128bbac 100644
--- a/arch/arm/mach-ixp4xx/Kconfig
+++ b/arch/arm/mach-ixp4xx/Kconfig
@@ -230,7 +230,6 @@ config IXP4XX_QMGR
 
 config IXP4XX_NPE
 	tristate "IXP4xx Network Processor Engine support"
-	select FW_LOADER
 	help
 	  This driver supports IXP4xx built-in network coprocessors
 	  and is automatically selected by Ethernet and HSS drivers.
diff --git a/arch/cris/arch-v32/drivers/Kconfig b/arch/cris/arch-v32/drivers/Kconfig
index 4fc16b4..575c6dd 100644
--- a/arch/cris/arch-v32/drivers/Kconfig
+++ b/arch/cris/arch-v32/drivers/Kconfig
@@ -331,7 +331,6 @@ config PCI
 config ETRAX_IOP_FW_LOAD
 	tristate "IO-processor hotplug firmware loading support"
 	depends on ETRAX_ARCH_V32
-	select FW_LOADER
 	help
 	  Enables IO-processor hotplug firmware loading support.
 
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c92fdcc..f7f8259 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1099,7 +1099,6 @@ config X86_REBOOTFIXUPS
 config MICROCODE
 	tristate "CPU microcode loading support"
 	depends on CPU_SUP_AMD || CPU_SUP_INTEL
-	select FW_LOADER
 	---help---
 
 	  If you say Y here, you will be able to update the microcode on
@@ -1119,7 +1118,6 @@ config MICROCODE_INTEL
 	bool "Intel microcode loading support"
 	depends on MICROCODE
 	default MICROCODE
-	select FW_LOADER
 	---help---
 	  This options enables microcode patch loading support for Intel
 	  processors.
@@ -1131,7 +1129,6 @@ config MICROCODE_INTEL
 config MICROCODE_AMD
 	bool "AMD microcode loading support"
 	depends on MICROCODE
-	select FW_LOADER
 	---help---
 	  If you select this option, microcode patch loading support for AMD
 	  processors will be enabled.
diff --git a/drivers/atm/Kconfig b/drivers/atm/Kconfig
index 31c6010..33c0558 100644
--- a/drivers/atm/Kconfig
+++ b/drivers/atm/Kconfig
@@ -328,7 +328,6 @@ config ATM_IA_DEBUG
 config ATM_FORE200E
 	tristate "FORE Systems 200E-series"
 	depends on (PCI || SBUS)
-	select FW_LOADER
 	---help---
 	  This is a driver for the FORE Systems 200E-series ATM adapter
 	  cards. It simultaneously supports PCA-200E and SBA-200E models
@@ -394,7 +393,6 @@ config ATM_HE_USE_SUNI
 config ATM_SOLOS
 	tristate "Solos ADSL2+ PCI Multiport card driver"
 	depends on PCI
-	select FW_LOADER
 	help
 	  Support for the Solos multiport ADSL2+ card.
 
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 2e77707..389d246 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -7,11 +7,9 @@ config BT_INTEL
 
 config BT_BCM
 	tristate
-	select FW_LOADER
 
 config BT_RTL
 	tristate
-	select FW_LOADER
 
 config BT_HCIBTUSB
 	tristate "HCI USB driver"
@@ -153,7 +151,6 @@ config BT_HCIUART_BCM
 config BT_HCIBCM203X
 	tristate "HCI BCM203x USB driver"
 	depends on USB
-	select FW_LOADER
 	help
 	  Bluetooth HCI BCM203x USB driver.
 	  This driver provides the firmware loading mechanism for the Broadcom
@@ -176,7 +173,6 @@ config BT_HCIBPA10X
 config BT_HCIBFUSB
 	tristate "HCI BlueFRITZ! USB driver"
 	depends on USB
-	select FW_LOADER
 	help
 	  Bluetooth HCI BlueFRITZ! USB driver.
 	  This driver provides support for Bluetooth USB devices with AVM
@@ -202,7 +198,6 @@ config BT_HCIDTL1
 config BT_HCIBT3C
 	tristate "HCI BT3C (PC Card) driver"
 	depends on PCMCIA
-	select FW_LOADER
 	help
 	  Bluetooth HCI BT3C (PC Card) driver.
 	  This driver provides support for Bluetooth PCMCIA devices with
@@ -265,7 +260,6 @@ config BT_MRVL
 config BT_MRVL_SDIO
 	tristate "Marvell BT-over-SDIO driver"
 	depends on BT_MRVL && MMC
-	select FW_LOADER
 	select WANT_DEV_COREDUMP
 	help
 	  The driver for Marvell Bluetooth chipsets with SDIO interface.
@@ -280,7 +274,6 @@ config BT_MRVL_SDIO
 config BT_ATH3K
 	tristate "Atheros firmware download driver"
 	depends on BT_HCIBTUSB
-	select FW_LOADER
 	help
 	  Bluetooth firmware download driver.
 	  This driver loads the firmware into the Atheros Bluetooth
diff --git a/drivers/crypto/qat/Kconfig b/drivers/crypto/qat/Kconfig
index 49bede2..3bd3fd9 100644
--- a/drivers/crypto/qat/Kconfig
+++ b/drivers/crypto/qat/Kconfig
@@ -8,7 +8,6 @@ config CRYPTO_DEV_QAT
 	select CRYPTO_SHA1
 	select CRYPTO_SHA256
 	select CRYPTO_SHA512
-	select FW_LOADER
 
 config CRYPTO_DEV_QAT_DH895xCC
 	tristate "Support for Intel(R) DH895xCC"
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 6517132..19a6db7 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -63,7 +63,6 @@ config EFI_PCDP
 config DELL_RBU
 	tristate "BIOS update support for DELL systems via sysfs"
 	depends on X86
-	select FW_LOADER
 	select FW_LOADER_USER_HELPER
 	help
 	 Say m if you want to have the option of updating the BIOS for your
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 47f2ce8..e0a043f 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -91,7 +91,6 @@ config DRM_TDFX
 config DRM_R128
 	tristate "ATI Rage 128"
 	depends on DRM && PCI
-	select FW_LOADER
 	help
 	  Choose this option if you have an ATI Rage 128 graphics card.  If M
 	  is selected, the module will be called r128.  AGP support for
@@ -103,7 +102,6 @@ config DRM_RADEON
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
-	select FW_LOADER
         select DRM_KMS_HELPER
 	select DRM_KMS_FB_HELPER
         select DRM_TTM
@@ -136,7 +134,6 @@ source "drivers/gpu/drm/i915/Kconfig"
 config DRM_MGA
 	tristate "Matrox g200/g400"
 	depends on DRM && PCI
-	select FW_LOADER
 	help
 	  Choose this option if you have a Matrox G200, G400 or G450 graphics
 	  card.  If M is selected, the module will be called mga.  AGP
diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
index 5ab13e7..135a5b8 100644
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -1,7 +1,6 @@
 config DRM_NOUVEAU
 	tristate "Nouveau (NVIDIA) cards"
 	depends on DRM && PCI
-        select FW_LOADER
 	select DRM_KMS_HELPER
 	select DRM_KMS_FB_HELPER
 	select DRM_TTM
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 05e4c6ff..e3e8a7c 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -105,7 +105,6 @@ config TOUCHSCREEN_AR1021_I2C
 config TOUCHSCREEN_ATMEL_MXT
 	tristate "Atmel mXT I2C Touchscreen"
 	depends on I2C
-	select FW_LOADER
 	help
 	  Say Y here if you have Atmel mXT series I2C touchscreen,
 	  such as AT42QT602240/ATMXT224, connected to your system.
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ec26dd1..76f2e00 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -221,7 +221,6 @@ config LEDS_LP3944
 config LEDS_LP55XX_COMMON
 	tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501"
 	depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
-	select FW_LOADER
 	help
 	  This option supports common operations for LP5521/5523/55231/5562/8501
 	  devices.
diff --git a/drivers/media/dvb-frontends/Kconfig b/drivers/media/dvb-frontends/Kconfig
index 97c151d..085b1dd 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -763,7 +763,6 @@ config DVB_LGS8GL5
 config DVB_LGS8GXX
 	tristate "Legend Silicon LGS8913/LGS8GL5/LGS8GXX DMB-TH demodulator"
 	depends on DVB_CORE && I2C
-	select FW_LOADER
 	default m if !MEDIA_SUBDRV_AUTOSELECT
 	help
 	  A DMB-TH tuner module. Say Y when you want to support this frontend.
diff --git a/drivers/media/pci/saa7164/Kconfig b/drivers/media/pci/saa7164/Kconfig
index a53db7d..db72970 100644
--- a/drivers/media/pci/saa7164/Kconfig
+++ b/drivers/media/pci/saa7164/Kconfig
@@ -2,7 +2,6 @@ config VIDEO_SAA7164
 	tristate "NXP SAA7164 support"
 	depends on DVB_CORE && VIDEO_DEV && PCI && I2C
 	select I2C_ALGOBIT
-	select FW_LOADER
 	select VIDEO_TUNER
 	select VIDEO_TVEEPROM
 	select VIDEOBUF_DVB
diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig
index b7b2e47..f54a935 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -60,7 +60,6 @@ config VIDEO_EXYNOS4_FIMC_IS
 	depends on HAS_DMA
 	select VIDEOBUF2_DMA_CONTIG
 	depends on OF
-	select FW_LOADER
 	help
 	  This is a V4L2 driver for Samsung EXYNOS4x12 SoC series
 	  FIMC-IS (Imaging Subsystem).
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 192f36f..631081a 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -214,7 +214,6 @@ config RADIO_WL1273
 	depends on I2C && VIDEO_V4L2
 	select MFD_CORE
 	select MFD_WL1273_CORE
-	select FW_LOADER
 	---help---
 	  Choose Y here if you have this FM radio chip.
 
diff --git a/drivers/media/usb/as102/Kconfig b/drivers/media/usb/as102/Kconfig
index 28aba00..5865029 100644
--- a/drivers/media/usb/as102/Kconfig
+++ b/drivers/media/usb/as102/Kconfig
@@ -1,7 +1,6 @@
 config DVB_AS102
 	tristate "Abilis AS102 DVB receiver"
 	depends on DVB_CORE && USB && I2C && INPUT
-	select FW_LOADER
 	help
 	  Choose Y or M here if you have a device containing an AS102
 
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 006242c..382bf64 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -489,7 +489,6 @@ config USB_SWITCH_FSA9480
 config LATTICE_ECP3_CONFIG
 	tristate "Lattice ECP3 FPGA bitstream configuration via SPI"
 	depends on SPI && SYSFS
-	select FW_LOADER
 	default	n
 	help
 	  This option enables support for bitstream configuration (programming
diff --git a/drivers/misc/ti-st/Kconfig b/drivers/misc/ti-st/Kconfig
index f34dcc5..b434391 100644
--- a/drivers/misc/ti-st/Kconfig
+++ b/drivers/misc/ti-st/Kconfig
@@ -6,7 +6,6 @@ menu "Texas Instruments shared transport line discipline"
 config TI_ST
 	tristate "Shared transport core driver"
 	depends on NET && GPIOLIB && TTY
-	select FW_LOADER
 	help
 	  This enables the shared transport core driver for TI
 	  BT / FM and GPS combo chips. This enables protocol drivers
diff --git a/drivers/net/ethernet/broadcom/Kconfig b/drivers/net/ethernet/broadcom/Kconfig
index a6f9142..3c30944 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -74,7 +74,6 @@ config BNX2
 	tristate "QLogic bnx2 support"
 	depends on PCI
 	select CRC32
-	select FW_LOADER
 	---help---
 	  This driver supports QLogic bnx2 gigabit Ethernet cards.
 
@@ -122,7 +121,6 @@ config BNX2X
 	tristate "Broadcom NetXtremeII 10Gb support"
 	depends on PCI
 	select PTP_1588_CLOCK
-	select FW_LOADER
 	select ZLIB_INFLATE
 	select LIBCRC32C
 	select MDIO
diff --git a/drivers/net/ethernet/chelsio/Kconfig b/drivers/net/ethernet/chelsio/Kconfig
index 7daa088..72ce340 100644
--- a/drivers/net/ethernet/chelsio/Kconfig
+++ b/drivers/net/ethernet/chelsio/Kconfig
@@ -49,7 +49,6 @@ config CHELSIO_T1_1G
 config CHELSIO_T3
 	tristate "Chelsio Communications T3 10Gb Ethernet support"
 	depends on PCI && INET
-	select FW_LOADER
 	select MDIO
 	---help---
 	  This driver supports Chelsio T3-based gigabit and 10Gb Ethernet
@@ -69,7 +68,6 @@ config CHELSIO_T3
 config CHELSIO_T4
 	tristate "Chelsio Communications T4/T5 Ethernet support"
 	depends on PCI && (IPV6 || IPV6=n)
-	select FW_LOADER
 	select MDIO
 	---help---
 	  This driver supports Chelsio T4 and T5 based gigabit, 10Gb Ethernet
diff --git a/drivers/net/ethernet/myricom/Kconfig b/drivers/net/ethernet/myricom/Kconfig
index 3932d08..07c2d4c 100644
--- a/drivers/net/ethernet/myricom/Kconfig
+++ b/drivers/net/ethernet/myricom/Kconfig
@@ -21,7 +21,6 @@ if NET_VENDOR_MYRI
 config MYRI10GE
 	tristate "Myricom Myri-10G Ethernet support"
 	depends on PCI && INET
-	select FW_LOADER
 	select CRC32
 	---help---
 	  This driver supports Myricom Myri-10G Dual Protocol interface in
diff --git a/drivers/net/ethernet/qlogic/Kconfig b/drivers/net/ethernet/qlogic/Kconfig
index d49cba1..23efb7f 100644
--- a/drivers/net/ethernet/qlogic/Kconfig
+++ b/drivers/net/ethernet/qlogic/Kconfig
@@ -30,7 +30,6 @@ config QLA3XXX
 config QLCNIC
 	tristate "QLOGIC QLCNIC 1/10Gb Converged Ethernet NIC Support"
 	depends on PCI
-	select FW_LOADER
 	---help---
 	  This driver supports QLogic QLE8240 and QLE8242 Converged Ethernet
 	  devices.
@@ -89,7 +88,6 @@ config QLGE
 config NETXEN_NIC
 	tristate "NetXen Multi port (1/10) Gigabit Ethernet NIC"
 	depends on PCI
-	select FW_LOADER
 	---help---
 	  This enables the support for NetXen's Gigabit Ethernet card.
 
diff --git a/drivers/net/ethernet/realtek/Kconfig b/drivers/net/ethernet/realtek/Kconfig
index ae5d027..e61f18f 100644
--- a/drivers/net/ethernet/realtek/Kconfig
+++ b/drivers/net/ethernet/realtek/Kconfig
@@ -103,7 +103,6 @@ config 8139_OLD_RX_RESET
 config R8169
 	tristate "Realtek 8169 gigabit ethernet support"
 	depends on PCI
-	select FW_LOADER
 	select CRC32
 	select MII
 	---help---
diff --git a/drivers/net/ethernet/toshiba/Kconfig b/drivers/net/ethernet/toshiba/Kconfig
index 5d244b6..ee7a7a7 100644
--- a/drivers/net/ethernet/toshiba/Kconfig
+++ b/drivers/net/ethernet/toshiba/Kconfig
@@ -43,7 +43,6 @@ config GELIC_WIRELESS
 config SPIDER_NET
 	tristate "Spider Gigabit Ethernet driver"
 	depends on PCI && PPC_IBM_CELL_BLADE
-	select FW_LOADER
 	select SUNGEM_PHY
 	---help---
 	  This driver supports the Gigabit Ethernet chips present on the
diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig
index a2c227b..52e8c92 100644
--- a/drivers/net/irda/Kconfig
+++ b/drivers/net/irda/Kconfig
@@ -243,7 +243,6 @@ comment "FIR device drivers"
 config USB_IRDA
 	tristate "IrDA USB dongles"
 	depends on IRDA && USB
-	select FW_LOADER
 	---help---
 	  Say Y here if you want to build support for the USB IrDA FIR Dongle
 	  device driver.  To compile it as a module, choose M here: the module
diff --git a/drivers/net/wimax/i2400m/Kconfig b/drivers/net/wimax/i2400m/Kconfig
index 71453db..c35a6936 100644
--- a/drivers/net/wimax/i2400m/Kconfig
+++ b/drivers/net/wimax/i2400m/Kconfig
@@ -2,7 +2,6 @@
 config WIMAX_I2400M
 	tristate
 	depends on WIMAX
-	select FW_LOADER
 
 comment "Enable USB support to see WiMAX USB drivers"
 	depends on USB = n
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 16604bd..1d7a035 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -35,7 +35,6 @@ config PCMCIA_RAYCS
 config LIBERTAS_THINFIRM
 	tristate "Marvell 8xxx Libertas WLAN driver support with thin firmware"
 	depends on MAC80211
-	select FW_LOADER
 	---help---
 	  A library for Marvell Libertas 8xxx devices using thinfirm.
 
@@ -76,7 +75,6 @@ config ATMEL
       depends on CFG80211 && (PCI || PCMCIA)
       select WIRELESS_EXT
       select WEXT_PRIV
-      select FW_LOADER
       select CRC32
        ---help---
         A driver 802.11b wireless cards based on the Atmel fast-vnet
@@ -100,7 +98,6 @@ config PCMCIA_ATMEL
 	tristate "Atmel at76c502/at76c504 PCMCIA cards"
 	depends on ATMEL && PCMCIA
 	select WIRELESS_EXT
-	select FW_LOADER
 	select CRC32
 	---help---
 	  Enable support for PCMCIA cards containing the
@@ -109,7 +106,6 @@ config PCMCIA_ATMEL
 config AT76C50X_USB
         tristate "Atmel at76c503/at76c505/at76c505a USB cards"
         depends on MAC80211 && USB
-        select FW_LOADER
         ---help---
           Enable support for USB Wireless devices using Atmel at76c503,
           at76c505 or at76c505a chips.
@@ -152,7 +148,6 @@ config PRISM54
 	select WIRELESS_EXT
 	select WEXT_SPY
 	select WEXT_PRIV
-	select FW_LOADER
 	---help---
 	  This enables support for FullMAC PCI/Cardbus prism54 devices. This
 	  driver is now deprecated in favor for the SoftMAC driver, p54pci.
@@ -171,7 +166,6 @@ config USB_ZD1201
 	depends on CFG80211 && USB
 	select WIRELESS_EXT
 	select WEXT_PRIV
-	select FW_LOADER
 	---help---
 	  Say Y if you want to use wireless LAN adapters based on the ZyDAS
 	  ZD1201 chip.
diff --git a/drivers/net/wireless/ath/ar5523/Kconfig b/drivers/net/wireless/ath/ar5523/Kconfig
index 0d320cc..d454af5 100644
--- a/drivers/net/wireless/ath/ar5523/Kconfig
+++ b/drivers/net/wireless/ath/ar5523/Kconfig
@@ -2,7 +2,6 @@ config AR5523
        tristate "Atheros AR5523 wireless driver support"
        depends on MAC80211 && USB
        select ATH_COMMON
-       select FW_LOADER
        ---help---
          This module add support for AR5523 based USB dongles such as D-Link
          DWL-G132, Netgear WPN111 and many more.
diff --git a/drivers/net/wireless/ath/carl9170/Kconfig b/drivers/net/wireless/ath/carl9170/Kconfig
index 1a796e5..d89abac 100644
--- a/drivers/net/wireless/ath/carl9170/Kconfig
+++ b/drivers/net/wireless/ath/carl9170/Kconfig
@@ -2,7 +2,6 @@ config CARL9170
 	tristate "Linux Community AR9170 802.11n USB support"
 	depends on USB && MAC80211
 	select ATH_COMMON
-	select FW_LOADER
 	select CRC32
 	help
 	  This is another driver for the Atheros "otus" 802.11n USB devices.
diff --git a/drivers/net/wireless/b43/Kconfig b/drivers/net/wireless/b43/Kconfig
index 759fb8d..b47afb8 100644
--- a/drivers/net/wireless/b43/Kconfig
+++ b/drivers/net/wireless/b43/Kconfig
@@ -3,7 +3,6 @@ config B43
 	depends on (BCMA_POSSIBLE || SSB_POSSIBLE) && MAC80211 && HAS_DMA
 	select BCMA if B43_BCMA
 	select SSB if B43_SSB
-	select FW_LOADER
 	---help---
 	  b43 is a driver for the Broadcom 43xx series wireless devices.
 
diff --git a/drivers/net/wireless/b43legacy/Kconfig b/drivers/net/wireless/b43legacy/Kconfig
index 1ffa288..4391c66 100644
--- a/drivers/net/wireless/b43legacy/Kconfig
+++ b/drivers/net/wireless/b43legacy/Kconfig
@@ -2,7 +2,6 @@ config B43LEGACY
 	tristate "Broadcom 43xx-legacy wireless support (mac80211 stack)"
 	depends on SSB_POSSIBLE && MAC80211 && HAS_DMA
 	select SSB
-	select FW_LOADER
 	---help---
 	  b43legacy is a driver for 802.11b devices from Broadcom (BCM4301 and
 	  BCM4303) and early model 802.11g chips (BCM4306 Ver. 2) used in the
diff --git a/drivers/net/wireless/brcm80211/Kconfig b/drivers/net/wireless/brcm80211/Kconfig
index fe3dc12..4901985 100644
--- a/drivers/net/wireless/brcm80211/Kconfig
+++ b/drivers/net/wireless/brcm80211/Kconfig
@@ -9,7 +9,6 @@ config BRCMSMAC
 	select NEW_LEDS if BCMA_DRIVER_GPIO
 	select LEDS_CLASS if BCMA_DRIVER_GPIO
 	select BRCMUTIL
-	select FW_LOADER
 	select CORDIC
 	---help---
 	  This module adds support for PCIe wireless adapters based on Broadcom
@@ -38,7 +37,6 @@ config BRCMFMAC_SDIO
 	depends on (MMC = y || MMC = BRCMFMAC)
 	depends on BRCMFMAC
 	select BRCMFMAC_PROTO_BCDC
-	select FW_LOADER
 	default y
 	---help---
 	  This option enables the SDIO bus interface support for Broadcom
@@ -50,7 +48,6 @@ config BRCMFMAC_USB
 	depends on (USB = y || USB = BRCMFMAC)
 	depends on BRCMFMAC
 	select BRCMFMAC_PROTO_BCDC
-	select FW_LOADER
 	---help---
 	  This option enables the USB bus interface support for Broadcom
 	  IEEE802.11n embedded FullMAC WLAN driver. Say Y if you want to
@@ -62,7 +59,6 @@ config BRCMFMAC_PCIE
 	depends on PCI
 	depends on HAS_DMA
 	select BRCMFMAC_PROTO_MSGBUF
-	select FW_LOADER
 	---help---
 	  This option enables the PCIE bus interface support for Broadcom
 	  IEEE802.11ac embedded FullMAC WLAN driver. Say Y if you want to
diff --git a/drivers/net/wireless/ipw2x00/Kconfig b/drivers/net/wireless/ipw2x00/Kconfig
index d6ec44d..ed43128 100644
--- a/drivers/net/wireless/ipw2x00/Kconfig
+++ b/drivers/net/wireless/ipw2x00/Kconfig
@@ -8,7 +8,6 @@ config IPW2100
 	select WIRELESS_EXT
 	select WEXT_SPY
 	select WEXT_PRIV
-	select FW_LOADER
 	select LIB80211
 	select LIBIPW
 	---help---
@@ -70,7 +69,6 @@ config IPW2200
 	select WIRELESS_EXT
 	select WEXT_SPY
 	select WEXT_PRIV
-	select FW_LOADER
 	select LIB80211
 	select LIBIPW
 	---help---
diff --git a/drivers/net/wireless/iwlegacy/Kconfig b/drivers/net/wireless/iwlegacy/Kconfig
index fb91972..faa68c9 100644
--- a/drivers/net/wireless/iwlegacy/Kconfig
+++ b/drivers/net/wireless/iwlegacy/Kconfig
@@ -1,6 +1,5 @@
 config IWLEGACY
 	tristate
-	select FW_LOADER
 	select NEW_LEDS
 	select LEDS_CLASS
 	select LEDS_TRIGGERS
diff --git a/drivers/net/wireless/iwlwifi/Kconfig b/drivers/net/wireless/iwlwifi/Kconfig
index 99f9760..e01e3c4 100644
--- a/drivers/net/wireless/iwlwifi/Kconfig
+++ b/drivers/net/wireless/iwlwifi/Kconfig
@@ -1,7 +1,6 @@
 config IWLWIFI
 	tristate "Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate-N (iwlwifi) "
 	depends on PCI && MAC80211 && HAS_IOMEM
-	select FW_LOADER
 	---help---
 	  Select to build the driver supporting the:
 
diff --git a/drivers/net/wireless/libertas/Kconfig b/drivers/net/wireless/libertas/Kconfig
index e6268ce..73c91ae 100644
--- a/drivers/net/wireless/libertas/Kconfig
+++ b/drivers/net/wireless/libertas/Kconfig
@@ -4,7 +4,6 @@ config LIBERTAS
 	select WIRELESS_EXT
 	select WEXT_SPY
 	select LIB80211
-	select FW_LOADER
 	---help---
 	  A library for Marvell Libertas 8xxx devices.
 
diff --git a/drivers/net/wireless/mwifiex/Kconfig b/drivers/net/wireless/mwifiex/Kconfig
index aa01c9b..2e6bb9d 100644
--- a/drivers/net/wireless/mwifiex/Kconfig
+++ b/drivers/net/wireless/mwifiex/Kconfig
@@ -11,7 +11,6 @@ config MWIFIEX
 config MWIFIEX_SDIO
 	tristate "Marvell WiFi-Ex Driver for SD8786/SD8787/SD8797/SD8887/SD8897"
 	depends on MWIFIEX && MMC
-	select FW_LOADER
 	---help---
 	  This adds support for wireless adapters based on Marvell
 	  8786/8787/8797/8887/8897 chipsets with SDIO interface.
@@ -22,7 +21,6 @@ config MWIFIEX_SDIO
 config MWIFIEX_PCIE
 	tristate "Marvell WiFi-Ex Driver for PCIE 8766/8897"
 	depends on MWIFIEX && PCI
-	select FW_LOADER
 	---help---
 	  This adds support for wireless adapters based on Marvell
 	  8766/8897 chipsets with PCIe interface.
@@ -33,7 +31,6 @@ config MWIFIEX_PCIE
 config MWIFIEX_USB
 	tristate "Marvell WiFi-Ex Driver for USB8766/8797/8897"
 	depends on MWIFIEX && USB
-	select FW_LOADER
 	---help---
 	  This adds support for wireless adapters based on Marvell
 	  8797/8897 chipset with USB interface.
diff --git a/drivers/net/wireless/orinoco/Kconfig b/drivers/net/wireless/orinoco/Kconfig
index f6fa3f4..bf8c1ad 100644
--- a/drivers/net/wireless/orinoco/Kconfig
+++ b/drivers/net/wireless/orinoco/Kconfig
@@ -6,7 +6,6 @@ config HERMES
 	select WIRELESS_EXT
 	select WEXT_SPY
 	select WEXT_PRIV
-	select FW_LOADER
 	select CRYPTO
 	select CRYPTO_MICHAEL_MIC
 	---help---
@@ -137,6 +136,5 @@ config PCMCIA_SPECTRUM
 config ORINOCO_USB
 	tristate "Agere Orinoco USB support"
 	depends on USB && HERMES
-	select FW_LOADER
 	---help---
 	  This driver is for USB versions of the Agere Orinoco card.
diff --git a/drivers/net/wireless/p54/Kconfig b/drivers/net/wireless/p54/Kconfig
index cdafb8c..f2cdec8 100644
--- a/drivers/net/wireless/p54/Kconfig
+++ b/drivers/net/wireless/p54/Kconfig
@@ -1,7 +1,6 @@
 config P54_COMMON
 	tristate "Softmac Prism54 support"
 	depends on MAC80211
-	select FW_LOADER
 	select CRC_CCITT
 	---help---
 	  This is common code for isl38xx/stlc45xx based modules.
diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
index 2b4ef25..9766408 100644
--- a/drivers/net/wireless/rt2x00/Kconfig
+++ b/drivers/net/wireless/rt2x00/Kconfig
@@ -244,7 +244,6 @@ config RT2X00_LIB
 
 config RT2X00_LIB_FIRMWARE
 	bool
-	select FW_LOADER
 
 config RT2X00_LIB_CRYPTO
 	bool
diff --git a/drivers/net/wireless/rtlwifi/Kconfig b/drivers/net/wireless/rtlwifi/Kconfig
index 5cf509d..8941e3e 100644
--- a/drivers/net/wireless/rtlwifi/Kconfig
+++ b/drivers/net/wireless/rtlwifi/Kconfig
@@ -119,7 +119,6 @@ config RTL8192CU
 
 config RTLWIFI
 	tristate
-	select FW_LOADER
 
 config RTLWIFI_PCI
 	tristate
diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
index 477a206..f1f6c4f 100644
--- a/drivers/net/wireless/ti/wl1251/Kconfig
+++ b/drivers/net/wireless/ti/wl1251/Kconfig
@@ -1,7 +1,6 @@
 menuconfig WL1251
 	tristate "TI wl1251 driver support"
 	depends on MAC80211
-	select FW_LOADER
 	select CRC7
 	---help---
 	  This will enable TI wl1251 driver support. The drivers make
diff --git a/drivers/net/wireless/ti/wlcore/Kconfig b/drivers/net/wireless/ti/wlcore/Kconfig
index 7c09954..538fbd9 100644
--- a/drivers/net/wireless/ti/wlcore/Kconfig
+++ b/drivers/net/wireless/ti/wlcore/Kconfig
@@ -1,7 +1,6 @@
 config WLCORE
 	tristate "TI wlcore support"
 	depends on WL_TI && MAC80211
-	select FW_LOADER
 	---help---
 	  This module contains the main code for TI WLAN chips.  It abstracts
 	  hardware-specific differences among different chipset families.
diff --git a/drivers/net/wireless/zd1211rw/Kconfig b/drivers/net/wireless/zd1211rw/Kconfig
index 95920581..eecc4ed 100644
--- a/drivers/net/wireless/zd1211rw/Kconfig
+++ b/drivers/net/wireless/zd1211rw/Kconfig
@@ -1,7 +1,6 @@
 config ZD1211RW
 	tristate "ZyDAS ZD1211/ZD1211B USB-wireless support"
 	depends on USB && MAC80211
-	select FW_LOADER
 	---help---
 	  This is a driver for the ZyDAS ZD1211/ZD1211B wireless
 	  chip, present in many USB-wireless adapters.
diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index a65f821..d3bbb11 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -37,7 +37,6 @@ config PCMCIA
 config PCMCIA_LOAD_CIS
 	bool "Load CIS updates from userspace"
 	depends on PCMCIA
-	select FW_LOADER
 	default y
 	help
 	  Some PCMCIA cards require an updated Card Information Structure (CIS)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 5e343ba..71ee9e3 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -5,7 +5,6 @@ config REMOTEPROC
 	tristate
 	depends on HAS_DMA
 	select CRC32
-	select FW_LOADER
 	select VIRTIO
 	select VIRTUALIZATION
 
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index b021bcb..27a3c3e 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1091,7 +1091,6 @@ config SCSI_SYM53C8XX_MMIO
 config SCSI_IPR
 	tristate "IBM Power Linux RAID adapter support"
 	depends on PCI && SCSI && ATA
-	select FW_LOADER
 	---help---
 	  This driver supports the IBM Power Linux family RAID adapters.
 	  This includes IBM pSeries 5712, 5703, 5709, and 570A, as well
diff --git a/drivers/scsi/aic94xx/Kconfig b/drivers/scsi/aic94xx/Kconfig
index c83fe75..0ed391d 100644
--- a/drivers/scsi/aic94xx/Kconfig
+++ b/drivers/scsi/aic94xx/Kconfig
@@ -28,7 +28,6 @@ config SCSI_AIC94XX
 	tristate "Adaptec AIC94xx SAS/SATA support"
 	depends on PCI
 	select SCSI_SAS_LIBSAS
-	select FW_LOADER
 	help
 		This driver supports Adaptec's SAS/SATA 3Gb/s 64 bit PCI-X
 		AIC94xx chip based host adapters.
diff --git a/drivers/scsi/csiostor/Kconfig b/drivers/scsi/csiostor/Kconfig
index 7c7e508..daf3524 100644
--- a/drivers/scsi/csiostor/Kconfig
+++ b/drivers/scsi/csiostor/Kconfig
@@ -2,7 +2,6 @@ config SCSI_CHELSIO_FCOE
 	tristate "Chelsio Communications FCoE support"
 	depends on PCI && SCSI
 	depends on SCSI_FC_ATTRS
-	select FW_LOADER
 	help
 	  This driver supports FCoE Offload functionality over
 	  Chelsio T4-based 10Gb Converged Network Adapters.
diff --git a/drivers/scsi/mvsas/Kconfig b/drivers/scsi/mvsas/Kconfig
index 78f7e20..280db51 100644
--- a/drivers/scsi/mvsas/Kconfig
+++ b/drivers/scsi/mvsas/Kconfig
@@ -29,7 +29,6 @@ config SCSI_MVSAS
 	tristate "Marvell 88SE64XX/88SE94XX SAS/SATA support"
 	depends on PCI
 	select SCSI_SAS_LIBSAS
-	select FW_LOADER
 	help
 		This driver supports Marvell's SAS/SATA 3Gb/s PCI-E 88SE64XX and 6Gb/s
 		PCI-E 88SE94XX chip based host adapters.
diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig
index 33f60c9..2bbe0c3 100644
--- a/drivers/scsi/qla2xxx/Kconfig
+++ b/drivers/scsi/qla2xxx/Kconfig
@@ -2,7 +2,6 @@ config SCSI_QLA_FC
 	tristate "QLogic QLA2XXX Fibre Channel Support"
 	depends on PCI && SCSI
 	depends on SCSI_FC_ATTRS
-	select FW_LOADER
 	---help---
 	This qla2xxx driver supports all QLogic Fibre Channel
 	PCI and PCIe host adapters.
diff --git a/drivers/staging/rtl8192e/rtl8192e/Kconfig b/drivers/staging/rtl8192e/rtl8192e/Kconfig
index 282e293..ad82bc3 100644
--- a/drivers/staging/rtl8192e/rtl8192e/Kconfig
+++ b/drivers/staging/rtl8192e/rtl8192e/Kconfig
@@ -5,5 +5,4 @@ config RTL8192E
 	select WIRELESS_EXT
 	select WEXT_PRIV
 	select CRYPTO
-	select FW_LOADER
 	---help---
diff --git a/drivers/staging/rtl8712/Kconfig b/drivers/staging/rtl8712/Kconfig
index f160eee..b94b0f0 100644
--- a/drivers/staging/rtl8712/Kconfig
+++ b/drivers/staging/rtl8712/Kconfig
@@ -3,7 +3,6 @@ config R8712U
 	depends on WLAN && USB
 	select WIRELESS_EXT
 	select WEXT_PRIV
-	select FW_LOADER
 	---help---
 	This option adds the Realtek RTL8712 USB device such as the D-Link DWA-130.
 	If built as a module, it will be called r8712u.
diff --git a/drivers/staging/vt6656/Kconfig b/drivers/staging/vt6656/Kconfig
index b602ef1..142e231 100644
--- a/drivers/staging/vt6656/Kconfig
+++ b/drivers/staging/vt6656/Kconfig
@@ -1,7 +1,6 @@
 config VT6656
 	tristate "VIA Technologies VT6656 support"
 	depends on MAC80211 && USB && WLAN && m
-	select FW_LOADER
 	---help---
 	This is a vendor-written driver for VIA VT6656.
 
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index c01f450..17c87a9 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -210,7 +210,6 @@ config ROCKETPORT
 config CYCLADES
 	tristate "Cyclades async mux support"
 	depends on SERIAL_NONSTANDARD && (PCI || ISA)
-	select FW_LOADER
 	---help---
 	  This driver supports Cyclades Z and Y multiserial boards.
 	  You would need something like this to connect more than two modems to
@@ -239,7 +238,6 @@ config CYZ_INTR
 config MOXA_INTELLIO
 	tristate "Moxa Intellio support"
 	depends on SERIAL_NONSTANDARD && (ISA || EISA || PCI)
-	select FW_LOADER
 	help
 	  Say Y here if you have a Moxa Intellio multiport serial card.
 
@@ -307,7 +305,6 @@ config NOZOMI
 config ISI
 	tristate "Multi-Tech multiport card support"
 	depends on SERIAL_NONSTANDARD && PCI
-	select FW_LOADER
 	help
 	  This is a driver for the Multi-Tech cards which provide several
 	  serial ports.  The driver is experimental and can currently only be
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 43b61f8..e6556bf 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -931,7 +931,6 @@ config SERIAL_ICOM
 	tristate "IBM Multiport Serial Adapter"
 	depends on PCI && PPC_PSERIES
 	select SERIAL_CORE
-	select FW_LOADER
 	help
 	  This driver is for a family of multiport serial adapters
 	  including 2 port RVX, 2 port internal modem, 4 port internal
@@ -1158,7 +1157,6 @@ config SERIAL_QE
 	tristate "Freescale QUICC Engine serial port support"
 	depends on QUICC_ENGINE
 	select SERIAL_CORE
-	select FW_LOADER
 	default n
 	help
 	  This driver supports the QE serial ports on Freescale embedded
diff --git a/drivers/usb/atm/Kconfig b/drivers/usb/atm/Kconfig
index 0f92294..ec577f8 100644
--- a/drivers/usb/atm/Kconfig
+++ b/drivers/usb/atm/Kconfig
@@ -19,7 +19,6 @@ if USB_ATM
 
 config USB_SPEEDTOUCH
 	tristate "Speedtouch USB support"
-	select FW_LOADER
 	help
 	  Say Y here if you have an SpeedTouch USB or SpeedTouch 330
 	  modem.  In order to use your modem you will need to install the 
@@ -31,7 +30,6 @@ config USB_SPEEDTOUCH
 
 config USB_CXACRU
 	tristate "Conexant AccessRunner USB support"
-	select FW_LOADER
 	help
 	  Say Y here if you have an ADSL USB modem based on the Conexant
 	  AccessRunner chipset.  In order to use your modem you will need to
@@ -43,7 +41,6 @@ config USB_CXACRU
 
 config USB_UEAGLEATM
 	tristate "ADI 930 and eagle USB DSL modem"
-	select FW_LOADER
 	help
 	  Say Y here if you have an ADSL USB modem based on the ADI 930
 	  or eagle chipset. In order to use your modem you will need to
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index f7a7fc2..84eda08 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -214,7 +214,6 @@ config USB_EHSET_TEST_FIXTURE
 
 config USB_ISIGHTFW
 	tristate "iSight firmware loading support"
-	select FW_LOADER
 	help
 	  This driver loads firmware for USB Apple iSight cameras, allowing
 	  them to be driven by the USB video class driver available at
diff --git a/drivers/uwb/Kconfig b/drivers/uwb/Kconfig
index c204094..a16b240 100644
--- a/drivers/uwb/Kconfig
+++ b/drivers/uwb/Kconfig
@@ -58,7 +58,6 @@ config UWB_WHCI
 config UWB_I1480U
         tristate "Support for Intel Wireless UWB Link 1480 HWA"
         depends on UWB_HWA
-        select FW_LOADER
         help
          This driver enables support for the i1480 when connected via
          USB. It consists of a firmware uploader that will enable it
diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
index 8545da9..5bba047 100644
--- a/sound/drivers/Kconfig
+++ b/sound/drivers/Kconfig
@@ -14,7 +14,6 @@ config SND_OPL4_LIB
 
 config SND_VX_LIB
 	tristate
-	select FW_LOADER
 	select SND_HWDEP
 	select SND_PCM
 
diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
index 0216475..82349f9 100644
--- a/sound/isa/Kconfig
+++ b/sound/isa/Kconfig
@@ -383,7 +383,6 @@ config SND_SBAWE
 config SND_SB16_CSP
 	bool "Sound Blaster 16/AWE CSP support"
 	depends on (SND_SB16 || SND_SBAWE) && (BROKEN || !PPC)
-	select FW_LOADER
 	help
 	  Say Y here to include support for the CSP core.  This special
 	  coprocessor can do variable tasks like various compression and
@@ -393,7 +392,6 @@ config SND_SSCAPE
 	tristate "Ensoniq SoundScape driver"
 	select SND_MPU401_UART
 	select SND_WSS_LIB
-	select FW_LOADER
 	help
 	  Say Y here to include support for Ensoniq SoundScape 
 	  and Ensoniq OEM soundcards.
@@ -412,7 +410,6 @@ config SND_SSCAPE
 
 config SND_WAVEFRONT
 	tristate "Turtle Beach Maui,Tropez,Tropez+ (Wavefront)"
-	select FW_LOADER
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
@@ -426,7 +423,6 @@ config SND_WAVEFRONT
 config SND_MSND_PINNACLE
 	tristate "Turtle Beach MultiSound Pinnacle/Fiji driver"
 	depends on X86
-	select FW_LOADER
 	select SND_MPU401_UART
 	select SND_PCM
 	help
@@ -439,7 +435,6 @@ config SND_MSND_PINNACLE
 config SND_MSND_CLASSIC
 	tristate "Support for Turtle Beach MultiSound Classic, Tahiti, Monterey"
 	depends on X86
-	select FW_LOADER
 	select SND_MPU401_UART
 	select SND_PCM
 	help
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index edfc1b8..f357a3d 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -63,7 +63,6 @@ config SND_ALI5451
 config SND_ASIHPI
 	tristate "AudioScience ASIxxxx"
 	depends on X86
-	select FW_LOADER
 	select SND_PCM
 	select SND_HWDEP
 	help
@@ -257,7 +256,6 @@ config SND_CS46XX
 	tristate "Cirrus Logic (Sound Fusion) CS4280/CS461x/CS462x/CS463x"
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
-	select FW_LOADER
 	help
 	  Say Y here to include support for Cirrus Logic CS4610/CS4612/
 	  CS4614/CS4615/CS4622/CS4624/CS4630/CS4280 chips.
@@ -314,7 +312,6 @@ config SND_CTXFI
 
 config SND_DARLA20
 	tristate "(Echoaudio) Darla20"
-	select FW_LOADER
 	select SND_PCM
 	help
 	  Say 'Y' or 'M' to include support for Echoaudio Darla.
@@ -324,7 +321,6 @@ config SND_DARLA20
 
 config SND_GINA20
 	tristate "(Echoaudio) Gina20"
-	select FW_LOADER
 	select SND_PCM
 	help
 	  Say 'Y' or 'M' to include support for Echoaudio Gina.
@@ -334,7 +330,6 @@ config SND_GINA20
 
 config SND_LAYLA20
 	tristate "(Echoaudio) Layla20"
-	select FW_LOADER
 	select SND_RAWMIDI
 	select SND_PCM
 	help
@@ -345,7 +340,6 @@ config SND_LAYLA20
 
 config SND_DARLA24
 	tristate "(Echoaudio) Darla24"
-	select FW_LOADER
 	select SND_PCM
 	help
 	  Say 'Y' or 'M' to include support for Echoaudio Darla24.
@@ -355,7 +349,6 @@ config SND_DARLA24
 
 config SND_GINA24
 	tristate "(Echoaudio) Gina24"
-	select FW_LOADER
 	select SND_PCM
 	help
 	  Say 'Y' or 'M' to include support for Echoaudio Gina24.
@@ -365,7 +358,6 @@ config SND_GINA24
 
 config SND_LAYLA24
 	tristate "(Echoaudio) Layla24"
-	select FW_LOADER
 	select SND_RAWMIDI
 	select SND_PCM
 	help
@@ -376,7 +368,6 @@ config SND_LAYLA24
 
 config SND_MONA
 	tristate "(Echoaudio) Mona"
-	select FW_LOADER
 	select SND_RAWMIDI
 	select SND_PCM
 	help
@@ -387,7 +378,6 @@ config SND_MONA
 
 config SND_MIA
 	tristate "(Echoaudio) Mia"
-	select FW_LOADER
 	select SND_RAWMIDI
 	select SND_PCM
 	help
@@ -398,7 +388,6 @@ config SND_MIA
 
 config SND_ECHO3G
 	tristate "(Echoaudio) 3G cards"
-	select FW_LOADER
 	select SND_RAWMIDI
 	select SND_PCM
 	help
@@ -409,7 +398,6 @@ config SND_ECHO3G
 
 config SND_INDIGO
 	tristate "(Echoaudio) Indigo"
-	select FW_LOADER
 	select SND_PCM
 	help
 	  Say 'Y' or 'M' to include support for Echoaudio Indigo.
@@ -419,7 +407,6 @@ config SND_INDIGO
 
 config SND_INDIGOIO
 	tristate "(Echoaudio) Indigo IO"
-	select FW_LOADER
 	select SND_PCM
 	help
 	  Say 'Y' or 'M' to include support for Echoaudio Indigo IO.
@@ -429,7 +416,6 @@ config SND_INDIGOIO
 
 config SND_INDIGODJ
 	tristate "(Echoaudio) Indigo DJ"
-	select FW_LOADER
 	select SND_PCM
 	help
 	  Say 'Y' or 'M' to include support for Echoaudio Indigo DJ.
@@ -439,7 +425,6 @@ config SND_INDIGODJ
 
 config SND_INDIGOIOX
 	tristate "(Echoaudio) Indigo IOx"
-	select FW_LOADER
 	select SND_PCM
 	help
 	  Say 'Y' or 'M' to include support for Echoaudio Indigo IOx.
@@ -449,7 +434,6 @@ config SND_INDIGOIOX
 
 config SND_INDIGODJX
 	tristate "(Echoaudio) Indigo DJx"
-	select FW_LOADER
 	select SND_PCM
 	help
 	  Say 'Y' or 'M' to include support for Echoaudio Indigo DJx.
@@ -459,7 +443,6 @@ config SND_INDIGODJX
 
 config SND_EMU10K1
 	tristate "Emu10k1 (SB Live!, Audigy, E-mu APS)"
-	select FW_LOADER
 	select SND_HWDEP
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
@@ -581,7 +564,6 @@ config SND_FM801_TEA575X_BOOL
 
 config SND_HDSP
 	tristate "RME Hammerfall DSP Audio"
-	select FW_LOADER
 	select SND_HWDEP
 	select SND_RAWMIDI
 	select SND_PCM
@@ -720,7 +702,6 @@ config SND_MAESTRO3_INPUT
 
 config SND_MIXART
 	tristate "Digigram miXart"
-	select FW_LOADER
 	select SND_HWDEP
 	select SND_PCM
 	help
@@ -741,7 +722,6 @@ config SND_NM256
 
 config SND_PCXHR
 	tristate "Digigram PCXHR"
-	select FW_LOADER
 	select SND_PCM
 	select SND_HWDEP
 	help
@@ -752,7 +732,6 @@ config SND_PCXHR
 
 config SND_RIPTIDE
 	tristate "Conexant Riptide"
-	select FW_LOADER
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig
index 117bf5c..36db8e3 100644
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -86,7 +86,6 @@ config SND_HDA_INPUT_BEEP_MODE
 
 config SND_HDA_PATCH_LOADER
 	bool "Support initialization patch loading for HD-audio"
-	select FW_LOADER
 	select SND_HDA_RECONFIG
 	help
 	  Say Y here to allow the HD-audio driver to load a pseudo
@@ -193,7 +192,6 @@ config SND_HDA_CODEC_CA0132_DSP
 	bool "Support new DSP code for CA0132 codec"
 	depends on SND_HDA_CODEC_CA0132
 	select SND_HDA_DSP_LOADER
-	select FW_LOADER
 	help
 	  Say Y here to enable the DSP for Creative CA0132 for extended
 	  features like equalizer or echo cancellation.
diff --git a/sound/soc/sh/Kconfig b/sound/soc/sh/Kconfig
index 07114b0..0856d5e 100644
--- a/sound/soc/sh/Kconfig
+++ b/sound/soc/sh/Kconfig
@@ -32,7 +32,6 @@ config SND_SOC_SH4_SIU
 	select DMA_ENGINE
 	select DMADEVICES
 	select SH_DMAE
-	select FW_LOADER
 
 config SND_SOC_RCAR
 	tristate "R-Car series SRU/SCU/SSIU/SSI support"
diff --git a/sound/usb/Kconfig b/sound/usb/Kconfig
index a452ad7..50bd312 100644
--- a/sound/usb/Kconfig
+++ b/sound/usb/Kconfig
@@ -103,7 +103,6 @@ config SND_USB_US122L
 
 config SND_USB_6FIRE
         tristate "TerraTec DMX 6Fire USB"
-        select FW_LOADER
         select BITREVERSE
         select SND_RAWMIDI
         select SND_PCM
-- 
2.3.2.209.gd67f9d5.dirty

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Borislav Petkov]

On Thu, May 21, 2015 at 01:45:49PM -0700, Luis R. Rodriguez wrote:
> The above history is just *one* set of reasons to remove all kernel
> "select FW_LOADER" entries. Another simple reason is that since
> FW_LOADER can only be disabled by an EXPERT and it defaults to y
> its now a superfluous select. We will ensure things build for you
> if using EXPERT but if you have selected EXPERT you should know
> what run time requirements you need.

Couple of notes only:

So the "depends" thing is a step backwards IMO because people would have
to go and enable FW_LOADER first. For the microcode loader, at least,
"select" is perfectly fine.

There's also the other aspect that this FW_LOADER thing ends up enabled
on 99.9% (!?) of the distro installations anyway, right? I.e., there's
always something needing firmware from userspace.

So the current "default y" behind EXPERT is probably the correct thing
anyway.

So yeah, send me the x86 microcode loader patch, I'll take it.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Borislav Petkov]

On Fri, May 22, 2015 at 12:21:29AM +0200, Borislav Petkov wrote:
> On Thu, May 21, 2015 at 01:45:49PM -0700, Luis R. Rodriguez wrote:
> > The above history is just *one* set of reasons to remove all kernel
> > "select FW_LOADER" entries. Another simple reason is that since
> > FW_LOADER can only be disabled by an EXPERT and it defaults to y
> > its now a superfluous select. We will ensure things build for you
> > if using EXPERT but if you have selected EXPERT you should know
> > what run time requirements you need.
> 
> Couple of notes only:

One thing I forgot last night: what about randconfigs? All that
functionality which selects FW_LOADER, won't boot anymore, right? I
mean, there are provisions to build fine even with FW_LOADER unset but
if you want to boot-test those kernels, you will artificially fail due
to missing request_firmware* things...

Yap, just triggered one:

$ make randconfig; grep -E "(MICROCODE|FW_LOADER)" .config
scripts/kconfig/conf  --randconfig Kconfig
KCONFIG_SEED=0xE14FBE97
warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG which has unmet direct dependencies (USB_SUPPORT && USB && PM)
warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG which has unmet direct dependencies (USB_SUPPORT && USB && PM)
warning: (SND_SOC_INTEL_BYTCR_RT5640_MACH && SND_SOC_INTEL_CHT_BSW_RT5672_MACH && SND_SOC_INTEL_CHT_BSW_RT5645_MACH) selects SND_SST_IPC_ACPI which has unmet direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC && ACPI)
#
# configuration written to .config
#
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
# CONFIG_FW_LOADER is not set

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Geert Uytterhoeven]

Hi Boris,

On Fri, May 22, 2015 at 8:53 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Fri, May 22, 2015 at 12:21:29AM +0200, Borislav Petkov wrote:
>> On Thu, May 21, 2015 at 01:45:49PM -0700, Luis R. Rodriguez wrote:
>> > The above history is just *one* set of reasons to remove all kernel
>> > "select FW_LOADER" entries. Another simple reason is that since
>> > FW_LOADER can only be disabled by an EXPERT and it defaults to y
>> > its now a superfluous select. We will ensure things build for you
>> > if using EXPERT but if you have selected EXPERT you should know
>> > what run time requirements you need.
>>
>> Couple of notes only:

> So the "depends" thing is a step backwards IMO because people would have
> to go and enable FW_LOADER first. For the microcode loader, at least,
> "select" is perfectly fine.

That's what the EXPERT protection is for.
FW_LOADER will always be enabled, unless people think they're smarter
than they are, and enable EXPERT, and disable FW_LOADER.

> One thing I forgot last night: what about randconfigs? All that
> functionality which selects FW_LOADER, won't boot anymore, right? I
> mean, there are provisions to build fine even with FW_LOADER unset but
> if you want to boot-test those kernels, you will artificially fail due
> to missing request_firmware* things...

If you expect to _boot_ randconfig kernels, you better disable EXPERT.
Still, your kernel can fail to boot due to some other critical dependency
(does your kernel support your CPU?).

If you want to boot randconfig kernels, create an allrandomconfig file
listing all options that must have a certain value:

$ cat allrandomconfig
CONFIG_EXPERT=n
CONFIG_MY_CRITICAL_FEATURE=y
...
$

and use "make randconfig KCONFIG_ALLCONFIG=1".

> ECO tip #101: Trim your mails when you reply.

You trimmed too much, so I had to readd it manually ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Borislav Petkov]

On Fri, May 22, 2015 at 09:11:34AM +0200, Geert Uytterhoeven wrote:
> That's what the EXPERT protection is for.
> FW_LOADER will always be enabled, unless people think they're smarter
> than they are, and enable EXPERT, and disable FW_LOADER.

I know. I was just making the negative aspect of "depends" vs "select"
in that particular case, explicit. Just so that it is mentioned in the
conversation.

> If you want to boot randconfig kernels, create an allrandomconfig file
> listing all options that must have a certain value:
> 
> $ cat allrandomconfig
> CONFIG_EXPERT=n
> CONFIG_MY_CRITICAL_FEATURE=y
> ...
> $
> 
> and use "make randconfig KCONFIG_ALLCONFIG=1".

I do that but does everyone who builds randconfigs? I had to go and look
what variables Kbuild honors and prep an all.config and yadda yadda...

So maybe we should put that as a note somewhere for randconfig-building
people.

> You trimmed too much, so I had to readd it manually ;-)

Yeah, that's what mail threads are for.

People tend to reply to a huuge mail with one sentence, bury it
somewhere on page gazillion and one and not trim the rest. Antisocial
behavior, that. :-P

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Geert Uytterhoeven]

On Fri, May 22, 2015 at 9:41 AM, Borislav Petkov <bp@alien8.de> wrote:
>> If you want to boot randconfig kernels, create an allrandomconfig file
>> listing all options that must have a certain value:
>>
>> $ cat allrandomconfig
>> CONFIG_EXPERT=n
>> CONFIG_MY_CRITICAL_FEATURE=y
>> ...
>> $
>>
>> and use "make randconfig KCONFIG_ALLCONFIG=1".
>
> I do that but does everyone who builds randconfigs? I had to go and look
> what variables Kbuild honors and prep an all.config and yadda yadda...

The ones who just build them probably not (unless they care about a specific
case), which increases build coverage, so that's good.

The ones who boot them probably do, else they'll find out the hard way...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Borislav Petkov]

On Fri, May 22, 2015 at 09:45:46AM +0200, Geert Uytterhoeven wrote:
> The ones who just build them probably not (unless they care about a
> specific case), which increases build coverage, so that's good.

Right.

> The ones who boot them probably do, else they'll find out the hard
> way...

Right, and this is what I wanted to avoid or at least save people the
trouble. Maybe randconfig builders should be expert enough to be able to
figure that out on their own.

:-)

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Paul Bolle]

On Fri, 2015-05-22 at 09:11 +0200, Geert Uytterhoeven wrote:
> On Fri, May 22, 2015 at 8:53 AM, Borislav Petkov <bp@alien8.de> wrote:
> > One thing I forgot last night: what about randconfigs? All that
> > functionality which selects FW_LOADER, won't boot anymore, right? I
> > mean, there are provisions to build fine even with FW_LOADER unset but
> > if you want to boot-test those kernels, you will artificially fail due
> > to missing request_firmware* things...

Luis also tried to explain to me that disabling FW_LOADER shouldn't make
the build fail. (And, of course, we could decide to not care about
randconfig builds that have EXPERT set. Maybe we could even special case
EXPERT in randconfig. But that would make randconfig builds less useful.
That's a separate issue, anyhow.)

> If you expect to _boot_ randconfig kernels, you better disable EXPERT.
> Still, your kernel can fail to boot due to some other critical dependency
> (does your kernel support your CPU?).
> 
> If you want to boot randconfig kernels, create an allrandomconfig file
> listing all options that must have a certain value:
> 
> $ cat allrandomconfig
> CONFIG_EXPERT=n
> CONFIG_MY_CRITICAL_FEATURE=y
> ...
> $
> 
> and use "make randconfig KCONFIG_ALLCONFIG=1".

Booting (truly) randconfig builds is like booting allyesconfig or
allnoconfig builds: no one sane should do that, right?


Paul Bolle

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Geert Uytterhoeven]

On Fri, May 22, 2015 at 10:17 AM, Paul Bolle <pebolle@tiscali.nl> wrote:
> Booting (truly) randconfig builds is like booting allyesconfig or
> allnoconfig builds: no one sane should do that, right?

allyesconfig should boot, modulo size limitations in boot loaders and
early kernel setup.

(No, commit 486df8bc4627bdfc ("m68k: Increase initial mapping to 8 or 16 MiB
 if possible") is not good enough ;-)

$ size linux-m68k-allyesconfig/vmlinux
   text   data    bss    dec    hex filename
42540590 2438292 1645336 46624218 2c76dda linux-m68k-allyesconfig/vmlinux
$

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Borislav Petkov]

On Fri, May 22, 2015 at 10:17:48AM +0200, Paul Bolle wrote:
> Luis also tried to explain to me that disabling FW_LOADER shouldn't
> make the build fail.

It doesn't. There are #else provisions in the header which define empty
functions returning -EINVAL and so on.

> Booting (truly) randconfig builds is like booting allyesconfig or
> allnoconfig builds: no one sane should do that, right?

Why not? It doesn't hurt to try to boot them in a guest. It sometimes
triggers valid issues.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Paul Bolle]

On Fri, 2015-05-22 at 08:53 +0200, Borislav Petkov wrote:
> One thing I forgot last night: what about randconfigs? All that
> functionality which selects FW_LOADER, won't boot anymore, right? I
> mean, there are provisions to build fine even with FW_LOADER unset but
> if you want to boot-test those kernels, you will artificially fail due
> to missing request_firmware* things...
> 
> Yap, just triggered one:
> 
> $ make randconfig; grep -E "(MICROCODE|FW_LOADER)" .config
> scripts/kconfig/conf  --randconfig Kconfig
> KCONFIG_SEED=0xE14FBE97
> warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG which has unmet direct dependencies (USB_SUPPORT && USB && PM)
> warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG which has unmet direct dependencies (USB_SUPPORT && USB && PM)
> warning: (SND_SOC_INTEL_BYTCR_RT5640_MACH && SND_SOC_INTEL_CHT_BSW_RT5672_MACH && SND_SOC_INTEL_CHT_BSW_RT5645_MACH) selects SND_SST_IPC_ACPI which has unmet direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC && ACPI)

Those missing dependencies look unrelated to not having FW_LOADER set.
Did I miss something here?

Thanks,


Paul Bolle

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Takashi Iwai]

At Fri, 22 May 2015 10:17:48 +0200,
Paul Bolle wrote:
> 
> On Fri, 2015-05-22 at 09:11 +0200, Geert Uytterhoeven wrote:
> > On Fri, May 22, 2015 at 8:53 AM, Borislav Petkov <bp@alien8.de> wrote:
> > > One thing I forgot last night: what about randconfigs? All that
> > > functionality which selects FW_LOADER, won't boot anymore, right? I
> > > mean, there are provisions to build fine even with FW_LOADER unset but
> > > if you want to boot-test those kernels, you will artificially fail due
> > > to missing request_firmware* things...
> 
> Luis also tried to explain to me that disabling FW_LOADER shouldn't make
> the build fail. (And, of course, we could decide to not care about
> randconfig builds that have EXPERT set. Maybe we could even special case
> EXPERT in randconfig. But that would make randconfig builds less useful.
> That's a separate issue, anyhow.)

But FW_LOADER is a tristate, so it might be inconsistent if selected
randomly?  Luis' patch doesn't add depends but just removes select.


Takashi

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Borislav Petkov]

On Fri, May 22, 2015 at 10:32:39AM +0200, Paul Bolle wrote:
> Those missing dependencies look unrelated to not having FW_LOADER set.
> Did I miss something here?

I just pasted what appeared on the console here. You can ignore them.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Paul Bolle]

On Fri, 2015-05-22 at 10:44 +0200, Takashi Iwai wrote:
> At Fri, 22 May 2015 10:17:48 +0200,
> Paul Bolle wrote:
> > Luis also tried to explain to me that disabling FW_LOADER shouldn't make
> > the build fail. (And, of course, we could decide to not care about
> > randconfig builds that have EXPERT set. Maybe we could even special case
> > EXPERT in randconfig. But that would make randconfig builds less useful.
> > That's a separate issue, anyhow.)
> 
> But FW_LOADER is a tristate, so it might be inconsistent if selected
> randomly?  Luis' patch doesn't add depends but just removes select.

include/linux/firmware.h contains:
    #if defined(CONFIG_FW_LOADER) || (defined(CONFIG_FW_LOADER_MODULE) && defined(MODULE)
    int request_firmware(const struct firmware **fw, const char *name,
                         struct device *device);
    [...]
    #else
    static inline int request_firmware(const struct firmware **fw,
                                       const char *name,
                                       struct device *device)
    {
            return -EINVAL;
    }
    [...]
    #endif

So I _think_ the build should be fine.

But, in case of built-in users of request_firmware() and friends,
actually using that build might not go as expected. But if you set
EXPERT and disable FW_LOADER, or as you point out, set it to 'm', you
own the pieces when things break, don't you?

But now I'm doing Luis' job. I didn't sign off on that patch! So let's
hope Luis thought of all the corner cases.


Paul Bolle

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Paul Bolle]

On Thu, 2015-05-21 at 13:45 -0700, Luis R. Rodriguez wrote:
> Paul also insists that *there is no reason* to think that current logic
> of the kconfig tools, as it is currently implemented, is flawed [2].

> [1] https://lkml.org/lkml/2015/5/8/748

(It should be noted that Russell King taught me the approach I took
there. Before Russell did that I found dependency errors involving
recursive selects, ie most of them, rather baffling.

Any flaws in that message are entirely mine, of course.)

> [2] https://lkml.org/lkml/2015/5/18/835

"insist" is pushing things a bit too far. "claims" or "stated"?


Paul Bolle

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Takashi Iwai]

At Fri, 22 May 2015 11:06:37 +0200,
Paul Bolle wrote:
> 
> On Fri, 2015-05-22 at 10:44 +0200, Takashi Iwai wrote:
> > At Fri, 22 May 2015 10:17:48 +0200,
> > Paul Bolle wrote:
> > > Luis also tried to explain to me that disabling FW_LOADER shouldn't make
> > > the build fail. (And, of course, we could decide to not care about
> > > randconfig builds that have EXPERT set. Maybe we could even special case
> > > EXPERT in randconfig. But that would make randconfig builds less useful.
> > > That's a separate issue, anyhow.)
> > 
> > But FW_LOADER is a tristate, so it might be inconsistent if selected
> > randomly?  Luis' patch doesn't add depends but just removes select.
> 
> include/linux/firmware.h contains:
>     #if defined(CONFIG_FW_LOADER) || (defined(CONFIG_FW_LOADER_MODULE) && defined(MODULE)
>     int request_firmware(const struct firmware **fw, const char *name,
>                          struct device *device);
>     [...]
>     #else
>     static inline int request_firmware(const struct firmware **fw,
>                                        const char *name,
>                                        struct device *device)
>     {
>             return -EINVAL;
>     }
>     [...]
>     #endif
> 
> So I _think_ the build should be fine.

Ah, OK, that would work.

> But, in case of built-in users of request_firmware() and friends,
> actually using that build might not go as expected. But if you set
> EXPERT and disable FW_LOADER, or as you point out, set it to 'm', you
> own the pieces when things break, don't you?

Yeah, I'm not against it, too.  My concern is only about the silent
breakage.

Thinking of this again, I also concluded that removing the mostly
superfluous "select FW_LOADER" would make things easier in the end.

> But now I'm doing Luis' job. I didn't sign off on that patch! So let's
> hope Luis thought of all the corner cases.

Heh, let's hope we all reach to a happy end.


thanks,

Takashi

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Luis R. Rodriguez]

On Fri, May 22, 2015 at 1:44 AM, Takashi Iwai <tiwai@suse.de> wrote:
> At Fri, 22 May 2015 10:17:48 +0200,
> Paul Bolle wrote:
>>
>> On Fri, 2015-05-22 at 09:11 +0200, Geert Uytterhoeven wrote:
>> > On Fri, May 22, 2015 at 8:53 AM, Borislav Petkov <bp@alien8.de> wrote:
>> > > One thing I forgot last night: what about randconfigs? All that
>> > > functionality which selects FW_LOADER, won't boot anymore, right? I
>> > > mean, there are provisions to build fine even with FW_LOADER unset but
>> > > if you want to boot-test those kernels, you will artificially fail due
>> > > to missing request_firmware* things...
>>
>> Luis also tried to explain to me that disabling FW_LOADER shouldn't make
>> the build fail. (And, of course, we could decide to not care about
>> randconfig builds that have EXPERT set. Maybe we could even special case
>> EXPERT in randconfig. But that would make randconfig builds less useful.
>> That's a separate issue, anyhow.)
>
> But FW_LOADER is a tristate, so it might be inconsistent if selected
> randomly?  Luis' patch doesn't add depends but just removes select.

We could go both ways, either remove the "select" or replace it with
"depends on". As you note keeping the "depends on" ensures run time
sanity for the possible tristate mismatches, but this is an EXPERT
concern. The crux of what option to go with is:

  Should we concern ourselves with run time configuration issues when
folks enable EXPERT?

Without EXPERT all run time configurations are vetted to run as
FW_LOADER defaults to y. If we go down the path of removing the select
completely we'd be taking a position that we could at least ensure
EXPERT builds will work, but we cannot vet for not run time sanity of
such build. I favor simplicity so would prefer to nuke the select
completely and if we're really concerned about EXPERT users tristate
mismatch misconfiguration why not just replace tristate with bool for
FW_LOADER. That would do us the service of simplifying that code a
bit, and leave only in place one way for folks that enable EXPERT to
shoot themselves in the foot with FW_LOADER?

  Luis

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Dmitry Torokhov]

On Fri, May 22, 2015 at 10:43:12AM -0700, Luis R. Rodriguez wrote:
> On Fri, May 22, 2015 at 1:44 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > At Fri, 22 May 2015 10:17:48 +0200,
> > Paul Bolle wrote:
> >>
> >> On Fri, 2015-05-22 at 09:11 +0200, Geert Uytterhoeven wrote:
> >> > On Fri, May 22, 2015 at 8:53 AM, Borislav Petkov <bp@alien8.de> wrote:
> >> > > One thing I forgot last night: what about randconfigs? All that
> >> > > functionality which selects FW_LOADER, won't boot anymore, right? I
> >> > > mean, there are provisions to build fine even with FW_LOADER unset but
> >> > > if you want to boot-test those kernels, you will artificially fail due
> >> > > to missing request_firmware* things...
> >>
> >> Luis also tried to explain to me that disabling FW_LOADER shouldn't make
> >> the build fail. (And, of course, we could decide to not care about
> >> randconfig builds that have EXPERT set. Maybe we could even special case
> >> EXPERT in randconfig. But that would make randconfig builds less useful.
> >> That's a separate issue, anyhow.)
> >
> > But FW_LOADER is a tristate, so it might be inconsistent if selected
> > randomly?  Luis' patch doesn't add depends but just removes select.
> 
> We could go both ways, either remove the "select" or replace it with
> "depends on". As you note keeping the "depends on" ensures run time
> sanity for the possible tristate mismatches, but this is an EXPERT
> concern. The crux of what option to go with is:
> 
>   Should we concern ourselves with run time configuration issues when
> folks enable EXPERT?

Yes.

dtor@dtor-ws:~/kernel/master$ grep -r CONFIG_EXPERT /boot/config*
/boot/config-3.13.0-49-generic:CONFIG_EXPERT=y
/boot/config-3.13.0-52-generic:CONFIG_EXPERT=y

This is distro config and that is what many people use as a base for
their own configs.

> 
> Without EXPERT all run time configurations are vetted to run as
> FW_LOADER defaults to y. If we go down the path of removing the select
> completely we'd be taking a position that we could at least ensure
> EXPERT builds will work, but we cannot vet for not run time sanity of
> such build. I favor simplicity so would prefer to nuke the select
> completely and if we're really concerned about EXPERT users tristate
> mismatch misconfiguration why not just replace tristate with bool for
> FW_LOADER. That would do us the service of simplifying that code a
> bit, and leave only in place one way for folks that enable EXPERT to
> shoot themselves in the foot with FW_LOADER?

I am afraid that we are moving into wrong direction here. Why don't we
look into Kconfig to teach it the difference between forced selection
and dependency instead?

Thanks.

-- 
Dmitry

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Luis R. Rodriguez]

On Fri, May 22, 2015 at 10:57:11AM -0700, Dmitry Torokhov wrote:
> On Fri, May 22, 2015 at 10:43:12AM -0700, Luis R. Rodriguez wrote:
> > On Fri, May 22, 2015 at 1:44 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > > At Fri, 22 May 2015 10:17:48 +0200,
> > > Paul Bolle wrote:
> > >>
> > >> On Fri, 2015-05-22 at 09:11 +0200, Geert Uytterhoeven wrote:
> > >> > On Fri, May 22, 2015 at 8:53 AM, Borislav Petkov <bp@alien8.de> wrote:
> > >> > > One thing I forgot last night: what about randconfigs? All that
> > >> > > functionality which selects FW_LOADER, won't boot anymore, right? I
> > >> > > mean, there are provisions to build fine even with FW_LOADER unset but
> > >> > > if you want to boot-test those kernels, you will artificially fail due
> > >> > > to missing request_firmware* things...
> > >>
> > >> Luis also tried to explain to me that disabling FW_LOADER shouldn't make
> > >> the build fail. (And, of course, we could decide to not care about
> > >> randconfig builds that have EXPERT set. Maybe we could even special case
> > >> EXPERT in randconfig. But that would make randconfig builds less useful.
> > >> That's a separate issue, anyhow.)
> > >
> > > But FW_LOADER is a tristate, so it might be inconsistent if selected
> > > randomly?  Luis' patch doesn't add depends but just removes select.
> > 
> > We could go both ways, either remove the "select" or replace it with
> > "depends on". As you note keeping the "depends on" ensures run time
> > sanity for the possible tristate mismatches, but this is an EXPERT
> > concern. The crux of what option to go with is:
> > 
> >   Should we concern ourselves with run time configuration issues when
> > folks enable EXPERT?
> 
> Yes.
> 
> dtor@dtor-ws:~/kernel/master$ grep -r CONFIG_EXPERT /boot/config*
> /boot/config-3.13.0-49-generic:CONFIG_EXPERT=y
> /boot/config-3.13.0-52-generic:CONFIG_EXPERT=y
> 
> This is distro config and that is what many people use as a base for
> their own configs.

Smells Ubuntu'ish, and hence ChromeOS'ish :)

Either way SUSE kernels also have EXPERT=y as well.  Would not be surprised if
other major distributions also have EXPERT=y.

OK so we obviously care about EXPERT run time issues then, seems to kind
of defeat the purpose of EXPERT though, no? Makes me wonder what major options
are under EXPERT which most distros need. Also, are there no other runtime
configuration options tucked under EXPERT that we *do not* resolve right now?
Or should all be taken care of? If not then we are being inconsistent.
Both of these are side topics -- but since I have a feeling this might come
up again, it may be worth evaluation.

Following on topic: such distro configs would never have FW_LOADER as n or
m, though right? Is that sufficient for us to drop the select and not apply
the "depends on" replacement ? Or do we want to stick to the "depend on"?

Note that not changing this means we *will* eventually run into the
recursive dependency issue later, either with my FW API change patches
or some other future feature. Likewise for any other kconfig option
with similar semantics.

> > Without EXPERT all run time configurations are vetted to run as
> > FW_LOADER defaults to y. If we go down the path of removing the select
> > completely we'd be taking a position that we could at least ensure
> > EXPERT builds will work, but we cannot vet for not run time sanity of
> > such build. I favor simplicity so would prefer to nuke the select
> > completely and if we're really concerned about EXPERT users tristate
> > mismatch misconfiguration why not just replace tristate with bool for
> > FW_LOADER. That would do us the service of simplifying that code a
> > bit, and leave only in place one way for folks that enable EXPERT to
> > shoot themselves in the foot with FW_LOADER?
> 
> I am afraid that we are moving into wrong direction here. Why don't we
> look into Kconfig to teach it the difference between forced selection
> and dependency instead?

That was what I originally hinted we should try to do. See the implications
of the issue right now and my explanation of a whitelist [0], granted this
is just a description, I tried looking at the code and quickly gave up,
it was not clear how such a thing could be implemented :( I gave up after
Paul assured me this could not be an issue, or rather that the logic on
kconfig was correct.

FWIW, I think my original description of implications if this issue is not a
real bug is a bit more clearer than the ones me and Paul ended up reviewing.
The examples me and Paul reviewed are examples one can experiment if trying
to address and fix the issue at hand in the most simplest cases.

[0] https://lkml.org/lkml/2015/5/12/597

  Luis

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Dmitry Torokhov]

On Fri, May 22, 2015 at 08:19:24PM +0200, Luis R. Rodriguez wrote:
> On Fri, May 22, 2015 at 10:57:11AM -0700, Dmitry Torokhov wrote:
> > On Fri, May 22, 2015 at 10:43:12AM -0700, Luis R. Rodriguez wrote:
> > > On Fri, May 22, 2015 at 1:44 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > > > At Fri, 22 May 2015 10:17:48 +0200,
> > > > Paul Bolle wrote:
> > > >>
> > > >> On Fri, 2015-05-22 at 09:11 +0200, Geert Uytterhoeven wrote:
> > > >> > On Fri, May 22, 2015 at 8:53 AM, Borislav Petkov <bp@alien8.de> wrote:
> > > >> > > One thing I forgot last night: what about randconfigs? All that
> > > >> > > functionality which selects FW_LOADER, won't boot anymore, right? I
> > > >> > > mean, there are provisions to build fine even with FW_LOADER unset but
> > > >> > > if you want to boot-test those kernels, you will artificially fail due
> > > >> > > to missing request_firmware* things...
> > > >>
> > > >> Luis also tried to explain to me that disabling FW_LOADER shouldn't make
> > > >> the build fail. (And, of course, we could decide to not care about
> > > >> randconfig builds that have EXPERT set. Maybe we could even special case
> > > >> EXPERT in randconfig. But that would make randconfig builds less useful.
> > > >> That's a separate issue, anyhow.)
> > > >
> > > > But FW_LOADER is a tristate, so it might be inconsistent if selected
> > > > randomly?  Luis' patch doesn't add depends but just removes select.
> > > 
> > > We could go both ways, either remove the "select" or replace it with
> > > "depends on". As you note keeping the "depends on" ensures run time
> > > sanity for the possible tristate mismatches, but this is an EXPERT
> > > concern. The crux of what option to go with is:
> > > 
> > >   Should we concern ourselves with run time configuration issues when
> > > folks enable EXPERT?
> > 
> > Yes.
> > 
> > dtor@dtor-ws:~/kernel/master$ grep -r CONFIG_EXPERT /boot/config*
> > /boot/config-3.13.0-49-generic:CONFIG_EXPERT=y
> > /boot/config-3.13.0-52-generic:CONFIG_EXPERT=y
> > 
> > This is distro config and that is what many people use as a base for
> > their own configs.
> 
> Smells Ubuntu'ish, and hence ChromeOS'ish :)

Yes, this coming from Ubuntu, but ChromeOS is closer to Gentoo if
anything I'd say ;)

> 
> Either way SUSE kernels also have EXPERT=y as well.  Would not be surprised if
> other major distributions also have EXPERT=y.

Right, I believe Fedora has it set as well.

> 
> OK so we obviously care about EXPERT run time issues then, seems to kind
> of defeat the purpose of EXPERT though, no? Makes me wonder what major options
> are under EXPERT which most distros need.

Not major, rather tweaking the driver sets. Like expert V4L or HID
configs.

> Also, are there no other runtime
> configuration options tucked under EXPERT that we *do not* resolve right now?
> Or should all be taken care of? If not then we are being inconsistent.
> Both of these are side topics -- but since I have a feeling this might come
> up again, it may be worth evaluation.
> 
> Following on topic: such distro configs would never have FW_LOADER as n or
> m, though right? Is that sufficient for us to drop the select and not apply
> the "depends on" replacement ? Or do we want to stick to the "depend on"?

But the user who is not expecrt might drop it. The premise was "only
experts would have CONFIG_EXPERT and thus we do not care about
breakage". But if people use distro configs as a starting point they all
are "experts".

> 
> Note that not changing this means we *will* eventually run into the
> recursive dependency issue later, either with my FW API change patches
> or some other future feature. Likewise for any other kconfig option
> with similar semantics.
> 
> > > Without EXPERT all run time configurations are vetted to run as
> > > FW_LOADER defaults to y. If we go down the path of removing the select
> > > completely we'd be taking a position that we could at least ensure
> > > EXPERT builds will work, but we cannot vet for not run time sanity of
> > > such build. I favor simplicity so would prefer to nuke the select
> > > completely and if we're really concerned about EXPERT users tristate
> > > mismatch misconfiguration why not just replace tristate with bool for
> > > FW_LOADER. That would do us the service of simplifying that code a
> > > bit, and leave only in place one way for folks that enable EXPERT to
> > > shoot themselves in the foot with FW_LOADER?
> > 
> > I am afraid that we are moving into wrong direction here. Why don't we
> > look into Kconfig to teach it the difference between forced selection
> > and dependency instead?
> 
> That was what I originally hinted we should try to do. See the implications
> of the issue right now and my explanation of a whitelist [0], granted this
> is just a description, I tried looking at the code and quickly gave up,
> it was not clear how such a thing could be implemented :( I gave up after
> Paul assured me this could not be an issue, or rather that the logic on
> kconfig was correct.
> 
> FWIW, I think my original description of implications if this issue is not a
> real bug is a bit more clearer than the ones me and Paul ended up reviewing.
> The examples me and Paul reviewed are examples one can experiment if trying
> to address and fix the issue at hand in the most simplest cases.

So I see your GYM and LOCKER example, or better, the original FW &
CRYPTO warning and I wonder why do we actually go and check dependencies
of selected symbols when resolving given symbol. I.e. should we not
"cut" the select branches off and evaluate them on their own? I.e. when
we try to select a symbol we note the symbols it tries to select and
evaluate them on their own (selects still don't cascade down - right?)
and then evaluate "depends on" symbols?

Thanks.

-- 
Dmitry

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Luis R. Rodriguez]

Adding Josh, as I know he seems to be on an EXPERT crusade to tuck
away system calls for tinyconfig, so likely can chime in for some
insane EXPERT runtime issue that users can run into.

On Fri, May 22, 2015 at 11:52:07AM -0700, Dmitry Torokhov wrote:
> On Fri, May 22, 2015 at 08:19:24PM +0200, Luis R. Rodriguez wrote:
> > OK so we obviously care about EXPERT run time issues then, seems to kind
> > of defeat the purpose of EXPERT though, no? Makes me wonder what major options
> > are under EXPERT which most distros need.
> 
> Not major, rather tweaking the driver sets. Like expert V4L or HID
> configs.

Driver tweaks seems rather harmless compared to "trust me I know
what I'm doing" even for all run time cases.

So the question still stands -- are there any kconfig options which
depend on EXPERT which enable folks to screw up run time (not just driver
tweaks? If so, would it be good to separate the two types of expert
config options, one for tweaks, another for run time possible conflicts?

Reason I ask this is -- IMO we should not treat the possible EXPERT run time
conflicts of FW_LOADER specially and try to be consistent, if we are ensuring
EXPERT run time conflicts will work with FW_LOADER why not for others? If
we want the option to let an EXPERT kconfig option enable run time conflicts
maybe we need to split things up further.

> > Also, are there no other runtime
> > configuration options tucked under EXPERT that we *do not* resolve right now?
> > Or should all be taken care of? If not then we are being inconsistent.
> > Both of these are side topics -- but since I have a feeling this might come
> > up again, it may be worth evaluation.
> > 
> > Following on topic: such distro configs would never have FW_LOADER as n or
> > m, though right? Is that sufficient for us to drop the select and not apply
> > the "depends on" replacement ? Or do we want to stick to the "depend on"?
> 
> But the user who is not expert might drop it. The premise was "only
> experts would have CONFIG_EXPERT and thus we do not care about
> breakage". But if people use distro configs as a starting point they all
> are "experts".

Replacing "select FW_LOADER" with "depends on FW_LOADER", although still pegged
with EXPERT, would not allow EXPERT users (most folks we've determined now) to
disable FW_LOADER if a driver was selected that needed FW_LOADER, in fact I
could not also create a tristate conflict of say MICROCODE set to y and
FW_LOADER to m. Please let me know if I've missed something with testing this
though.

So unless I'm missing a corner case, it would seem replacing "select FW_LOADER"
with "depends on FW_LOADER" is a reasonable option so far. The subtleties lie
then now in since EXPERT is used by most distributions, everyone is an expert,
and:

  a) Do we want to be consistent about ensuring run time sanity of EXPERT?
  b) Should we split EXPERT into tweak / possible run time break options?

> > Note that not changing this means we *will* eventually run into the
> > recursive dependency issue later, either with my FW API change patches
> > or some other future feature. Likewise for any other kconfig option
> > with similar semantics.
> > 
> > > > Without EXPERT all run time configurations are vetted to run as
> > > > FW_LOADER defaults to y. If we go down the path of removing the select
> > > > completely we'd be taking a position that we could at least ensure
> > > > EXPERT builds will work, but we cannot vet for not run time sanity of
> > > > such build. I favor simplicity so would prefer to nuke the select
> > > > completely and if we're really concerned about EXPERT users tristate
> > > > mismatch misconfiguration why not just replace tristate with bool for
> > > > FW_LOADER. That would do us the service of simplifying that code a
> > > > bit, and leave only in place one way for folks that enable EXPERT to
> > > > shoot themselves in the foot with FW_LOADER?
> > > 
> > > I am afraid that we are moving into wrong direction here. Why don't we
> > > look into Kconfig to teach it the difference between forced selection
> > > and dependency instead?
> > 
> > That was what I originally hinted we should try to do. See the implications
> > of the issue right now and my explanation of a whitelist [0], granted this
> > is just a description, I tried looking at the code and quickly gave up,
> > it was not clear how such a thing could be implemented :( I gave up after
> > Paul assured me this could not be an issue, or rather that the logic on
> > kconfig was correct.
> > 
> > FWIW, I think my original description of implications if this issue is not a
> > real bug is a bit more clearer than the ones me and Paul ended up reviewing.
> > The examples me and Paul reviewed are examples one can experiment if trying
> > to address and fix the issue at hand in the most simplest cases.
> 
> So I see your GYM and LOCKER example, or better, the original FW &
> CRYPTO warning and I wonder why do we actually go and check dependencies
> of selected symbols when resolving given symbol.

I'm no kconfig expert and I wondered the same.

Perhaps Paul can elaborate.

> I.e. should we not
> "cut" the select branches off and evaluate them on their own? I.e. when
> we try to select a symbol we note the symbols it tries to select and
> evaluate them on their own (selects still don't cascade down - right?)
> and then evaluate "depends on" symbols?

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 4506 bytes --]

On 2015-05-22 14:52, Dmitry Torokhov wrote:
> On Fri, May 22, 2015 at 08:19:24PM +0200, Luis R. Rodriguez wrote:
>> On Fri, May 22, 2015 at 10:57:11AM -0700, Dmitry Torokhov wrote:
>>> On Fri, May 22, 2015 at 10:43:12AM -0700, Luis R. Rodriguez wrote:
>>>> On Fri, May 22, 2015 at 1:44 AM, Takashi Iwai <tiwai@suse.de> wrote:
>>>>> At Fri, 22 May 2015 10:17:48 +0200,
>>>>> Paul Bolle wrote:
>>>>>>
>>>>>> On Fri, 2015-05-22 at 09:11 +0200, Geert Uytterhoeven wrote:
>>>>>>> On Fri, May 22, 2015 at 8:53 AM, Borislav Petkov <bp@alien8.de> wrote:
>>>>>>>> One thing I forgot last night: what about randconfigs? All that
>>>>>>>> functionality which selects FW_LOADER, won't boot anymore, right? I
>>>>>>>> mean, there are provisions to build fine even with FW_LOADER unset but
>>>>>>>> if you want to boot-test those kernels, you will artificially fail due
>>>>>>>> to missing request_firmware* things...
>>>>>>
>>>>>> Luis also tried to explain to me that disabling FW_LOADER shouldn't make
>>>>>> the build fail. (And, of course, we could decide to not care about
>>>>>> randconfig builds that have EXPERT set. Maybe we could even special case
>>>>>> EXPERT in randconfig. But that would make randconfig builds less useful.
>>>>>> That's a separate issue, anyhow.)
>>>>>
>>>>> But FW_LOADER is a tristate, so it might be inconsistent if selected
>>>>> randomly?  Luis' patch doesn't add depends but just removes select.
>>>>
>>>> We could go both ways, either remove the "select" or replace it with
>>>> "depends on". As you note keeping the "depends on" ensures run time
>>>> sanity for the possible tristate mismatches, but this is an EXPERT
>>>> concern. The crux of what option to go with is:
>>>>
>>>>    Should we concern ourselves with run time configuration issues when
>>>> folks enable EXPERT?
>>>
>>> Yes.
>>>
>>> dtor@dtor-ws:~/kernel/master$ grep -r CONFIG_EXPERT /boot/config*
>>> /boot/config-3.13.0-49-generic:CONFIG_EXPERT=y
>>> /boot/config-3.13.0-52-generic:CONFIG_EXPERT=y
>>>
>>> This is distro config and that is what many people use as a base for
>>> their own configs.
>>
>> Smells Ubuntu'ish, and hence ChromeOS'ish :)
>
> Yes, this coming from Ubuntu, but ChromeOS is closer to Gentoo if
> anything I'd say ;)
>
Technically, ChromeOS _is_ Gentoo, just with a bunch of third party 
patches and configuration layered on top.  IMHO though, they really do 
have a good excuse for enabling CONFIG_EXPERT (namely, they have 
absolute control over pretty much the entire system, and run on 
specialized hardware).
>>
>> Either way SUSE kernels also have EXPERT=y as well.  Would not be surprised if
>> other major distributions also have EXPERT=y.
>
> Right, I believe Fedora has it set as well.
>
I'm pretty certain that Fedora does, and that Arch does as well.
>>
>> OK so we obviously care about EXPERT run time issues then, seems to kind
>> of defeat the purpose of EXPERT though, no? Makes me wonder what major options
>> are under EXPERT which most distros need.
>
> Not major, rather tweaking the driver sets. Like expert V4L or HID
> configs.
>
Of the people I know personally who build their own kernels, about 80% 
have EXPERT=y for exactly this reason, namely, they want finer control 
over driver options, and don't do anything to the options under the 
EXPERT menu.  Personally this is one of two reasons that I use EXPERT=y, 
the other being disabling the handful of deprecated syscalls at the top 
of the list (and disabling AIO when I'm building embedded systems).
>> Also, are there no other runtime
>> configuration options tucked under EXPERT that we *do not* resolve right now?
>> Or should all be taken care of? If not then we are being inconsistent.
>> Both of these are side topics -- but since I have a feeling this might come
>> up again, it may be worth evaluation.
>>
>> Following on topic: such distro configs would never have FW_LOADER as n or
>> m, though right? Is that sufficient for us to drop the select and not apply
>> the "depends on" replacement ? Or do we want to stick to the "depend on"?
>
> But the user who is not expecrt might drop it. The premise was "only
> experts would have CONFIG_EXPERT and thus we do not care about
> breakage". But if people use distro configs as a starting point they all
> are "experts".
>
Based on this, maybe the EXPERT stuff should be subdivided into driver 
options, and core API options under separate config options.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Geert Uytterhoeven]

On Fri, May 22, 2015 at 9:30 PM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:
>>> Either way SUSE kernels also have EXPERT=y as well.  Would not be
>>> surprised if
>>> other major distributions also have EXPERT=y.
>>
>> Right, I believe Fedora has it set as well.
>>
> I'm pretty certain that Fedora does, and that Arch does as well.

Perhaps they just use allmodconfig, which enables EXPERT ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Dmitry Torokhov]

On Fri, May 22, 2015 at 09:28:14PM +0200, Luis R. Rodriguez wrote:
> Adding Josh, as I know he seems to be on an EXPERT crusade to tuck
> away system calls for tinyconfig, so likely can chime in for some
> insane EXPERT runtime issue that users can run into.
> 
> On Fri, May 22, 2015 at 11:52:07AM -0700, Dmitry Torokhov wrote:
> > On Fri, May 22, 2015 at 08:19:24PM +0200, Luis R. Rodriguez wrote:
> > > OK so we obviously care about EXPERT run time issues then, seems to kind
> > > of defeat the purpose of EXPERT though, no? Makes me wonder what major options
> > > are under EXPERT which most distros need.
> > 
> > Not major, rather tweaking the driver sets. Like expert V4L or HID
> > configs.
> 
> Driver tweaks seems rather harmless compared to "trust me I know
> what I'm doing" even for all run time cases.
> 
> So the question still stands -- are there any kconfig options which
> depend on EXPERT which enable folks to screw up run time (not just driver
> tweaks? If so, would it be good to separate the two types of expert
> config options, one for tweaks, another for run time possible conflicts?
> 
> Reason I ask this is -- IMO we should not treat the possible EXPERT run time
> conflicts of FW_LOADER specially and try to be consistent, if we are ensuring
> EXPERT run time conflicts will work with FW_LOADER why not for others? If
> we want the option to let an EXPERT kconfig option enable run time conflicts
> maybe we need to split things up further.
> 
> > > Also, are there no other runtime
> > > configuration options tucked under EXPERT that we *do not* resolve right now?
> > > Or should all be taken care of? If not then we are being inconsistent.
> > > Both of these are side topics -- but since I have a feeling this might come
> > > up again, it may be worth evaluation.
> > > 
> > > Following on topic: such distro configs would never have FW_LOADER as n or
> > > m, though right? Is that sufficient for us to drop the select and not apply
> > > the "depends on" replacement ? Or do we want to stick to the "depend on"?
> > 
> > But the user who is not expert might drop it. The premise was "only
> > experts would have CONFIG_EXPERT and thus we do not care about
> > breakage". But if people use distro configs as a starting point they all
> > are "experts".
> 
> Replacing "select FW_LOADER" with "depends on FW_LOADER", although still pegged
> with EXPERT, would not allow EXPERT users (most folks we've determined now) to
> disable FW_LOADER if a driver was selected that needed FW_LOADER, in fact I
> could not also create a tristate conflict of say MICROCODE set to y and
> FW_LOADER to m. Please let me know if I've missed something with testing this
> though.
> 
> So unless I'm missing a corner case, it would seem replacing "select FW_LOADER"
> with "depends on FW_LOADER" is a reasonable option so far. The subtleties lie
> then now in since EXPERT is used by most distributions, everyone is an expert,
> and:
> 
>   a) Do we want to be consistent about ensuring run time sanity of EXPERT?
>   b) Should we split EXPERT into tweak / possible run time break options?
> 
> > > Note that not changing this means we *will* eventually run into the
> > > recursive dependency issue later, either with my FW API change patches
> > > or some other future feature. Likewise for any other kconfig option
> > > with similar semantics.
> > > 
> > > > > Without EXPERT all run time configurations are vetted to run as
> > > > > FW_LOADER defaults to y. If we go down the path of removing the select
> > > > > completely we'd be taking a position that we could at least ensure
> > > > > EXPERT builds will work, but we cannot vet for not run time sanity of
> > > > > such build. I favor simplicity so would prefer to nuke the select
> > > > > completely and if we're really concerned about EXPERT users tristate
> > > > > mismatch misconfiguration why not just replace tristate with bool for
> > > > > FW_LOADER. That would do us the service of simplifying that code a
> > > > > bit, and leave only in place one way for folks that enable EXPERT to
> > > > > shoot themselves in the foot with FW_LOADER?
> > > > 
> > > > I am afraid that we are moving into wrong direction here. Why don't we
> > > > look into Kconfig to teach it the difference between forced selection
> > > > and dependency instead?
> > > 
> > > That was what I originally hinted we should try to do. See the implications
> > > of the issue right now and my explanation of a whitelist [0], granted this
> > > is just a description, I tried looking at the code and quickly gave up,
> > > it was not clear how such a thing could be implemented :( I gave up after
> > > Paul assured me this could not be an issue, or rather that the logic on
> > > kconfig was correct.
> > > 
> > > FWIW, I think my original description of implications if this issue is not a
> > > real bug is a bit more clearer than the ones me and Paul ended up reviewing.
> > > The examples me and Paul reviewed are examples one can experiment if trying
> > > to address and fix the issue at hand in the most simplest cases.
> > 
> > So I see your GYM and LOCKER example, or better, the original FW &
> > CRYPTO warning and I wonder why do we actually go and check dependencies
> > of selected symbols when resolving given symbol.
> 
> I'm no kconfig expert

Me neither ;)

> and I wondered the same.
> 
> Perhaps Paul can elaborate.
> 
> > I.e. should we not
> > "cut" the select branches off and evaluate them on their own? I.e. when
> > we try to select a symbol we note the symbols it tries to select and
> > evaluate them on their own (selects still don't cascade down - right?)
> > and then evaluate "depends on" symbols?

By the way, to resolve your FW loader issue can you simply select CRYPTO
instead of depending on it? I believe that certain core facilities (such
as FW loaders, Crypto, etc) should be normally selected rather than
depended upon, just because of workflow. If user works with menuconfig
and has core facility disable he won't event be presented with an
option. So one has to perform several "passes" over menuconfig to slect
everything that is needed.

Thanks. 

-- 
Dmitry

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[josh]

On Fri, May 22, 2015 at 09:28:14PM +0200, Luis R. Rodriguez wrote:
> Adding Josh, as I know he seems to be on an EXPERT crusade to tuck
> away system calls for tinyconfig, so likely can chime in for some
> insane EXPERT runtime issue that users can run into.

Thanks.

> On Fri, May 22, 2015 at 11:52:07AM -0700, Dmitry Torokhov wrote:
> > On Fri, May 22, 2015 at 08:19:24PM +0200, Luis R. Rodriguez wrote:
> > > OK so we obviously care about EXPERT run time issues then, seems to kind
> > > of defeat the purpose of EXPERT though, no? Makes me wonder what major options
> > > are under EXPERT which most distros need.
> > 
> > Not major, rather tweaking the driver sets. Like expert V4L or HID
> > configs.
> 
> Driver tweaks seems rather harmless compared to "trust me I know
> what I'm doing" even for all run time cases.
> 
> So the question still stands -- are there any kconfig options which
> depend on EXPERT which enable folks to screw up run time (not just driver
> tweaks? If so, would it be good to separate the two types of expert
> config options, one for tweaks, another for run time possible conflicts?
> 
> Reason I ask this is -- IMO we should not treat the possible EXPERT run time
> conflicts of FW_LOADER specially and try to be consistent, if we are ensuring
> EXPERT run time conflicts will work with FW_LOADER why not for others? If
> we want the option to let an EXPERT kconfig option enable run time conflicts
> maybe we need to split things up further.

I don't think it should be possible, even with EXPERT, to disable an
option that a driver needs at runtime without disabling that driver.  If
the driver *optionally* needs something, but can work without it, it
shouldn't have "depends" or "select".

> > > Also, are there no other runtime
> > > configuration options tucked under EXPERT that we *do not* resolve right now?
> > > Or should all be taken care of? If not then we are being inconsistent.
> > > Both of these are side topics -- but since I have a feeling this might come
> > > up again, it may be worth evaluation.
> > > 
> > > Following on topic: such distro configs would never have FW_LOADER as n or
> > > m, though right? Is that sufficient for us to drop the select and not apply
> > > the "depends on" replacement ? Or do we want to stick to the "depend on"?
> > 
> > But the user who is not expert might drop it. The premise was "only
> > experts would have CONFIG_EXPERT and thus we do not care about
> > breakage". But if people use distro configs as a starting point they all
> > are "experts".
> 
> Replacing "select FW_LOADER" with "depends on FW_LOADER", although still pegged
> with EXPERT, would not allow EXPERT users (most folks we've determined now) to
> disable FW_LOADER if a driver was selected that needed FW_LOADER, in fact I
> could not also create a tristate conflict of say MICROCODE set to y and
> FW_LOADER to m. Please let me know if I've missed something with testing this
> though.
> 
> So unless I'm missing a corner case, it would seem replacing "select FW_LOADER"
> with "depends on FW_LOADER" is a reasonable option so far. The subtleties lie
> then now in since EXPERT is used by most distributions, everyone is an expert,
> and:
> 
>   a) Do we want to be consistent about ensuring run time sanity of EXPERT?
>   b) Should we split EXPERT into tweak / possible run time break options?

"depends on FW_LOADER" and "select FW_LOADER" are equivalent from the
point of view of what configs they allow; they differ in how the
dependency is shown in UIs.  "select" means you can always see the
drivers, and you can't turn off FW_LOADER until you turn off all of the
drivers.  "depends" means that if you disable FW_LOADER all the drivers
that depend on it disappear, and you can't turn them on unless you turn
on FW_LOADER (which however is always on when !EXPERT).

Either way, if you have FW_LOADER and a pile of drivers using it
enabled, you have to disable all the drivers before disabling FW_LOADER.
The behavior only differs when you have FW_LOADER disabled, which is a
sufficiently uncommon case that it doesn't matter deeply which approach
you take.  Personally, if FW_LOADER doesn't have any dependencies, I'd
favor the select, since it avoids the case of "wait, where is the driver
I expected and why can't I find it?".

However, from the sounds of things, you want to add a dependency to
FW_LOADER.  So in that case, yeah, switch to depends rather than
rewriting Kconfig, unless you're feeling really ambitious.

> > > Note that not changing this means we *will* eventually run into the
> > > recursive dependency issue later, either with my FW API change patches
> > > or some other future feature. Likewise for any other kconfig option
> > > with similar semantics.

By "recursive dependency issue", I'm guessing that someone wants to make
FW_LOADER depend on something else, which breaks because "select"
doesn't know how to recurse?

Ideally, someone should teach Kconfig to handle recursive dependencies,
but in the meantime using "depends" makes sense.

- Josh Triplett

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Luis R. Rodriguez]

On Fri, May 22, 2015 at 02:43:57PM -0700, josh@joshtriplett.org wrote:
> On Fri, May 22, 2015 at 09:28:14PM +0200, Luis R. Rodriguez wrote:
> > So the question still stands -- are there any kconfig options which
> > depend on EXPERT which enable folks to screw up run time (not just driver
> > tweaks?
> 
> I don't think it should be possible

OK, thanks!

> > So unless I'm missing a corner case, it would seem replacing "select FW_LOADER"
> > with "depends on FW_LOADER" is a reasonable option so far. The subtleties lie
> > then now in since EXPERT is used by most distributions, everyone is an expert,
> > and:
> > 
> >   a) Do we want to be consistent about ensuring run time sanity of EXPERT?
> >   b) Should we split EXPERT into tweak / possible run time break options?
> 
> "depends on FW_LOADER" and "select FW_LOADER" are equivalent from the
> point of view of what configs they allow; they differ in how the
> dependency is shown in UIs.
>
> However, from the sounds of things, you want to add a dependency to
> FW_LOADER.

Nope the recursive case was that a new component which depends on
FW_LOADER ended up selecting CRYPTO, and it turns out another driver
which depends on FW_LOADER also depended on CRYPTO so that in turn
creates a recursive dependency.

> So in that case, yeah, switch to depends rather than
> rewriting Kconfig, unless you're feeling really ambitious.

OK so switching to "depends on" is the winning contender so far.

> > > > Note that not changing this means we *will* eventually run into the
> > > > recursive dependency issue later, either with my FW API change patches
> > > > or some other future feature. Likewise for any other kconfig option
> > > > with similar semantics.
> 
> By "recursive dependency issue", I'm guessing that someone wants to make
> FW_LOADER depend on something else, which breaks because "select"
> doesn't know how to recurse?

Kind of, the issue actually was a new component which depends on FW_LOADER
and has crypto dependencies. Since the qat crypto driver selects FW_LOADER
but also has a set of crypto dependencies that creates a recursive dependency
loop.

> Ideally, someone should teach Kconfig to handle recursive dependencies,
> but in the meantime using "depends" makes sense.

Doesn't sound like anyone is that enthusiastic about that.

So... shall we just switch to "depends on" tree-wide then for FW_LOADER?

  Luis

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Herbert Xu]

On Sat, May 23, 2015 at 12:22:00AM +0200, Luis R. Rodriguez wrote:
> Kind of, the issue actually was a new component which depends on FW_LOADER
> and has crypto dependencies. Since the qat crypto driver selects FW_LOADER
> but also has a set of crypto dependencies that creates a recursive dependency
> loop.

Actually, how about making FW_SIG select FW_LOADER instead of
depending on it? I think this should break the cycle.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Luis R. Rodriguez]

On Fri, May 22, 2015 at 3:33 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Sat, May 23, 2015 at 12:22:00AM +0200, Luis R. Rodriguez wrote:
>> Kind of, the issue actually was a new component which depends on FW_LOADER
>> and has crypto dependencies. Since the qat crypto driver selects FW_LOADER
>> but also has a set of crypto dependencies that creates a recursive dependency
>> loop.
>
> Actually, how about making FW_SIG select FW_LOADER instead of
> depending on it? I think this should break the cycle.

Indeed, it does. Kind of odd, but works - and well if others run into
the recursive issue then we have two diverging solutions now:

  a) Either swap all "select FOO" to "depends on FOO" or,
  b) Change the offending "depends on FOO" to "select FOO"

So sticking to one seems to make Kconfig happy for recursive
dependency solving for now...

 Luis

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Josh Triplett]

On Fri, May 22, 2015 at 04:02:33PM -0700, Luis R. Rodriguez wrote:
> On Fri, May 22, 2015 at 3:33 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > On Sat, May 23, 2015 at 12:22:00AM +0200, Luis R. Rodriguez wrote:
> >> Kind of, the issue actually was a new component which depends on FW_LOADER
> >> and has crypto dependencies. Since the qat crypto driver selects FW_LOADER
> >> but also has a set of crypto dependencies that creates a recursive dependency
> >> loop.
> >
> > Actually, how about making FW_SIG select FW_LOADER instead of
> > depending on it? I think this should break the cycle.
> 
> Indeed, it does. Kind of odd, but works - and well if others run into
> the recursive issue then we have two diverging solutions now:
> 
>   a) Either swap all "select FOO" to "depends on FOO" or,
>   b) Change the offending "depends on FOO" to "select FOO"
> 
> So sticking to one seems to make Kconfig happy for recursive
> dependency solving for now...

For simplicity and avoidance of massive tree-wide patches, (b) seems
preferable in this case.

Long-term, I think ideally we should have *every* visible Kconfig option
always pulled in by "depends on" rather than "select", with visibility
and recursion handled by smarter tools.  That said, meddle not in the
internals of Kconfig, for it has many unshorn yaks (and yaccs).

- Josh Triplett

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Geert Uytterhoeven]

On Sat, May 23, 2015 at 1:02 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Fri, May 22, 2015 at 3:33 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>> On Sat, May 23, 2015 at 12:22:00AM +0200, Luis R. Rodriguez wrote:
>>> Kind of, the issue actually was a new component which depends on FW_LOADER
>>> and has crypto dependencies. Since the qat crypto driver selects FW_LOADER
>>> but also has a set of crypto dependencies that creates a recursive dependency
>>> loop.
>>
>> Actually, how about making FW_SIG select FW_LOADER instead of
>> depending on it? I think this should break the cycle.
>
> Indeed, it does. Kind of odd, but works - and well if others run into
> the recursive issue then we have two diverging solutions now:
>
>   a) Either swap all "select FOO" to "depends on FOO" or,
>   b) Change the offending "depends on FOO" to "select FOO"
>
> So sticking to one seems to make Kconfig happy for recursive
> dependency solving for now...

Yes, that works, too.

Perhaps Kconfig should start warning if it encounters a symbol
that is both selected and being depended on, even without detecting an
explicit recursive dependency?
That's gonna give tons of warnings, though...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Paul Bolle]

On Fri, 2015-05-22 at 22:12 +0200, Geert Uytterhoeven wrote:
> On Fri, May 22, 2015 at 9:30 PM, Austin S Hemmelgarn
> <ahferroin7@gmail.com> wrote:
> >>> Either way SUSE kernels also have EXPERT=y as well.  Would not be
> >>> surprised if
> >>> other major distributions also have EXPERT=y.
> >>
> >> Right, I believe Fedora has it set as well.
> >>
> > I'm pretty certain that Fedora does, and that Arch does as well.

Fedora doesn't set EXPERT, and as far as I can see, never has. Same goes
for EMBEDDED, which is the predecessor of EXPERT.

If EXPERT really turns out to be set on most distributions it will have
gone the way of EXPERIMENTAL: a warning sign that lost its impact
through overuse. Perhaps that's the way these things go. But I don't
think that has happened with EXPERT, not yet.


Paul Bolle

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Paul Bolle]

On Fri, 2015-05-22 at 14:43 -0700, josh@joshtriplett.org wrote:
> Ideally, someone should teach Kconfig to handle recursive dependencies,

I'm probably reading too much in this remark, but how should it handle
that other than returning an error because the configuration it's fed
makes it run in circles?


Paul Bolle

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Paul Bolle]

On Fri, 2015-05-22 at 21:28 +0200, Luis R. Rodriguez wrote: 
> > So I see your GYM and LOCKER example, or better, the original FW &
> > CRYPTO warning and I wonder why do we actually go and check dependencies
> > of selected symbols when resolving given symbol.
> 
> I'm no kconfig expert and I wondered the same.
> 
> Perhaps Paul can elaborate.

Because both the dependencies of a symbol and the select statements on
that symbol influence the set of values that is possible for that
symbol.


Paul Bolle

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Paul Bolle]

On Fri, 2015-05-22 at 11:52 -0700, Dmitry Torokhov wrote:
> selects still don't cascade down - right?

select statements trigger the select statements of the selected symbol,
if that's what you mean.


Paul Bolle

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Josh Triplett]

On Mon, May 25, 2015 at 12:55:17PM +0200, Paul Bolle wrote:
> On Fri, 2015-05-22 at 14:43 -0700, josh@joshtriplett.org wrote:
> > Ideally, someone should teach Kconfig to handle recursive dependencies,
> 
> I'm probably reading too much in this remark, but how should it handle
> that other than returning an error because the configuration it's fed
> makes it run in circles?

I don't mean cyclic dependencies (for which Kconfig should just report
an error, ideally including the full list of symbols forming the cycle).

I mean that Kconfig should do recursive dependency resolution.  If B
depends on A, and C depends on B, I should be able to turn on C
directly and have B and A enabled.

As an intermediate measure, it'd be *really* handy to be able to browse
in the curses UI directly from a symbol to the symbols it depends on to
quickly enable/disable them, rather than having to look at the list of
dependencies of a symbol, search for that symbol, remember the path the
search showed, and browse there manually.

- Josh Triplett

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Paul Bolle]

On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
> I don't mean cyclic dependencies (for which Kconfig should just report
> an error, ideally including the full list of symbols forming the cycle).
> 
> I mean that Kconfig should do recursive dependency resolution.

(My English might be letting me down here. Or my grasp of elementary
logic, for that matter. Recursive and cyclic are not really
interchangeable? Should Kconfig perhaps report a "Cyclic dependency
error"? )
 
> If B
> depends on A, and C depends on B, I should be able to turn on C
> directly and have B and A enabled.

And how should kconfig handle, say:
    - B depends on (A || D)
    - C depends on B

Should (B && D) be enabled or (B && A)? This is not meant as a
rhetorical question. But I do fear the complications for the choices
this idea might encounter are, at best, not worth the effort.

> As an intermediate measure, it'd be *really* handy to be able to browse
> in the curses UI directly from a symbol to the symbols it depends on to
> quickly enable/disable them, rather than having to look at the list of
> dependencies of a symbol, search for that symbol, remember the path the
> search showed, and browse there manually.

Probably. I'd rather not think about the UI involved when the symbol(s)
that should be enabled is (are) two or more levels down the chain. And
the odd "stacked" UI for searches in the curses tool adds to the fun.
But then again, I'm a the-glass-is-half-empty person.


Paul Bolle

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Josh Triplett]

On Mon, May 25, 2015 at 08:25:35PM +0200, Paul Bolle wrote:
> On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
> > I don't mean cyclic dependencies (for which Kconfig should just report
> > an error, ideally including the full list of symbols forming the cycle).
> > 
> > I mean that Kconfig should do recursive dependency resolution.
> 
> (My English might be letting me down here. Or my grasp of elementary
> logic, for that matter. Recursive and cyclic are not really
> interchangeable? Should Kconfig perhaps report a "Cyclic dependency
> error"? )

I do think that'd be a clearer message, yes.

For clarity: "recursive dependency resolution" as in "recursive
resolution of dependencies", not "resolution of recursive dependencies".

> > If B
> > depends on A, and C depends on B, I should be able to turn on C
> > directly and have B and A enabled.
> 
> And how should kconfig handle, say:
>     - B depends on (A || D)
>     - C depends on B
> 
> Should (B && D) be enabled or (B && A)? This is not meant as a
> rhetorical question. But I do fear the complications for the choices
> this idea might encounter are, at best, not worth the effort.

That's exactly the kind of problem that makes this difficult to do, and
has thus stopped anyone from working on it.  A fully general solution
requires a system that can also solve arbitrary logic problems, which is
not necessarily a feature.

The typical choice made by package management systems is to enable B and
A, preferring the leftmost dependency of B.  That's what Debian's apt
does, in the absence of conflicts.

For an initial solution, I'd suggest just recursing through "select"
dependencies; if C has "select B", and B has "select A", enabling C
should enable B and A.  Since you can't "select A || D", that seems
straightforward enough.  You can "select A if X", but for that, just
bail out if the value of the expression X is changed by any of the
select statements.

> > As an intermediate measure, it'd be *really* handy to be able to browse
> > in the curses UI directly from a symbol to the symbols it depends on to
> > quickly enable/disable them, rather than having to look at the list of
> > dependencies of a symbol, search for that symbol, remember the path the
> > search showed, and browse there manually.
> 
> Probably. I'd rather not think about the UI involved when the symbol(s)
> that should be enabled is (are) two or more levels down the chain. And
> the odd "stacked" UI for searches in the curses tool adds to the fun.
> But then again, I'm a the-glass-is-half-empty person.

I'm more thinking that if you're looking at an option, you should be
able to hit a key to see all the symbols that option depends on in a
list, then navigate to one of those symbols, and be taken to the menu
containing that symbol with the cursor on that symbol.  (You could then
hit a key to go "back" to where you were.)  It's not perfect, but it's
an improvement.

I'd also suggest that the search mechanism should produce a list that
can be browsed with the arrow keys, with enter taking you to the symbol.

- Josh Triplett

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[James Bottomley]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1661 bytes --]

On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
> On Mon, May 25, 2015 at 12:55:17PM +0200, Paul Bolle wrote:
> > On Fri, 2015-05-22 at 14:43 -0700, josh@joshtriplett.org wrote:
> > > Ideally, someone should teach Kconfig to handle recursive dependencies,
> > 
> > I'm probably reading too much in this remark, but how should it handle
> > that other than returning an error because the configuration it's fed
> > makes it run in circles?
> 
> I don't mean cyclic dependencies (for which Kconfig should just report
> an error, ideally including the full list of symbols forming the cycle).
> 
> I mean that Kconfig should do recursive dependency resolution.  If B
> depends on A, and C depends on B, I should be able to turn on C
> directly and have B and A enabled.

That's really hard in practise you have to make any symbol that selects
something depend on the dependencies of the selected symbol.  You can't
do this without involving a SAT solver.  A guy promised to do this a
couple of years ago, but the patches never materialised.  However, they
may exist somewhere if someone wants to take a look at completing it.

James

> As an intermediate measure, it'd be *really* handy to be able to browse
> in the curses UI directly from a symbol to the symbols it depends on to
> quickly enable/disable them, rather than having to look at the list of
> dependencies of a symbol, search for that symbol, remember the path the
> search showed, and browse there manually.
> 
> - Josh Triplett


ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Paul Bolle]

On Mon, 2015-05-25 at 12:06 -0700, Josh Triplett wrote:
> On Mon, May 25, 2015 at 08:25:35PM +0200, Paul Bolle wrote:
> > On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
> For clarity: "recursive dependency resolution" as in "recursive
> resolution of dependencies", not "resolution of recursive dependencies".

I feel a headache coming up.

> For an initial solution, I'd suggest just recursing through "select"
> dependencies; if C has "select B", and B has "select A", enabling C
> should enable B and A.  Since you can't "select A || D", that seems
> straightforward enough.  You can "select A if X", but for that, just
> bail out if the value of the expression X is changed by any of the
> select statements.

Actually, kconfig already recurses through select statements. (I haven't
checked, but I'd expect it to handle the "select A if X" case correctly
while doing the recursive select dance.)

Thanks,


Paul Bolle

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Josh Triplett]

On Mon, May 25, 2015 at 07:07:14PM +0000, James Bottomley wrote:
> On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
> > On Mon, May 25, 2015 at 12:55:17PM +0200, Paul Bolle wrote:
> > > On Fri, 2015-05-22 at 14:43 -0700, josh@joshtriplett.org wrote:
> > > > Ideally, someone should teach Kconfig to handle recursive dependencies,
> > > 
> > > I'm probably reading too much in this remark, but how should it handle
> > > that other than returning an error because the configuration it's fed
> > > makes it run in circles?
> > 
> > I don't mean cyclic dependencies (for which Kconfig should just report
> > an error, ideally including the full list of symbols forming the cycle).
> > 
> > I mean that Kconfig should do recursive dependency resolution.  If B
> > depends on A, and C depends on B, I should be able to turn on C
> > directly and have B and A enabled.
> 
> That's really hard in practise you have to make any symbol that selects
> something depend on the dependencies of the selected symbol.  You can't
> do this without involving a SAT solver.  A guy promised to do this a
> couple of years ago, but the patches never materialised.  However, they
> may exist somewhere if someone wants to take a look at completing it.

You can't do this in the completely general case without a SAT solver.
However, I think it's possible to help the user a bit more than than
Kconfig currently does without introducing a general dependency solver.

In particular, it'd be nice to have an easy way to see at a glance
"can't enable C because it depends on B", together with an easy way to
get to B to enable it to get to C.  User-guided dependency resolution
seems like an improvement over no dependency resolution.

- Josh Triplett

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[James Bottomley]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2391 bytes --]

On Mon, 2015-05-25 at 12:29 -0700, Josh Triplett wrote:
> On Mon, May 25, 2015 at 07:07:14PM +0000, James Bottomley wrote:
> > On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
> > > On Mon, May 25, 2015 at 12:55:17PM +0200, Paul Bolle wrote:
> > > > On Fri, 2015-05-22 at 14:43 -0700, josh@joshtriplett.org wrote:
> > > > > Ideally, someone should teach Kconfig to handle recursive dependencies,
> > > > 
> > > > I'm probably reading too much in this remark, but how should it handle
> > > > that other than returning an error because the configuration it's fed
> > > > makes it run in circles?
> > > 
> > > I don't mean cyclic dependencies (for which Kconfig should just report
> > > an error, ideally including the full list of symbols forming the cycle).
> > > 
> > > I mean that Kconfig should do recursive dependency resolution.  If B
> > > depends on A, and C depends on B, I should be able to turn on C
> > > directly and have B and A enabled.
> > 
> > That's really hard in practise you have to make any symbol that selects
> > something depend on the dependencies of the selected symbol.  You can't
> > do this without involving a SAT solver.  A guy promised to do this a
> > couple of years ago, but the patches never materialised.  However, they
> > may exist somewhere if someone wants to take a look at completing it.
> 
> You can't do this in the completely general case without a SAT solver.
> However, I think it's possible to help the user a bit more than than
> Kconfig currently does without introducing a general dependency solver.

Well the logically simplest way of doing that it to require that a
selected symbol can have no dependencies (but may select others) and to
make this what Kconfig enforces ... of course, our current Kconfig tree
violates this all over the place.

> In particular, it'd be nice to have an easy way to see at a glance
> "can't enable C because it depends on B", together with an easy way to
> get to B to enable it to get to C.  User-guided dependency resolution
> seems like an improvement over no dependency resolution.

Sure, but it's mostly people like us doing it and find . -name Kconfig\*
-exec grep -3 <symbol> {} /dev/null \; usually does the trick for me.

James

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Josh Triplett]

On Mon, May 25, 2015 at 09:29:51PM +0000, James Bottomley wrote:
> On Mon, 2015-05-25 at 12:29 -0700, Josh Triplett wrote:
> > On Mon, May 25, 2015 at 07:07:14PM +0000, James Bottomley wrote:
> > > On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
> > > > On Mon, May 25, 2015 at 12:55:17PM +0200, Paul Bolle wrote:
> > > > > On Fri, 2015-05-22 at 14:43 -0700, josh@joshtriplett.org wrote:
> > > > > > Ideally, someone should teach Kconfig to handle recursive dependencies,
> > > > > 
> > > > > I'm probably reading too much in this remark, but how should it handle
> > > > > that other than returning an error because the configuration it's fed
> > > > > makes it run in circles?
> > > > 
> > > > I don't mean cyclic dependencies (for which Kconfig should just report
> > > > an error, ideally including the full list of symbols forming the cycle).
> > > > 
> > > > I mean that Kconfig should do recursive dependency resolution.  If B
> > > > depends on A, and C depends on B, I should be able to turn on C
> > > > directly and have B and A enabled.
> > > 
> > > That's really hard in practise you have to make any symbol that selects
> > > something depend on the dependencies of the selected symbol.  You can't
> > > do this without involving a SAT solver.  A guy promised to do this a
> > > couple of years ago, but the patches never materialised.  However, they
> > > may exist somewhere if someone wants to take a look at completing it.
> > 
> > You can't do this in the completely general case without a SAT solver.
> > However, I think it's possible to help the user a bit more than than
> > Kconfig currently does without introducing a general dependency solver.
> 
> Well the logically simplest way of doing that it to require that a
> selected symbol can have no dependencies (but may select others) and to
> make this what Kconfig enforces ... of course, our current Kconfig tree
> violates this all over the place.

Or enforce that it has no disabled dependencies.

> > In particular, it'd be nice to have an easy way to see at a glance
> > "can't enable C because it depends on B", together with an easy way to
> > get to B to enable it to get to C.  User-guided dependency resolution
> > seems like an improvement over no dependency resolution.
> 
> Sure, but it's mostly people like us doing it and find . -name Kconfig\*
> -exec grep -3 <symbol> {} /dev/null \; usually does the trick for me.

That's not particularly convenient from the middle of menuconfig when
configuring a kernel.  It'd be nice to be able to navigate in one step
from a symbol to its dependencies within the menuconfig interface.

- Josh Triplett

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[James Bottomley]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3353 bytes --]

On Mon, 2015-05-25 at 17:47 -0700, Josh Triplett wrote:
> On Mon, May 25, 2015 at 09:29:51PM +0000, James Bottomley wrote:
> > On Mon, 2015-05-25 at 12:29 -0700, Josh Triplett wrote:
> > > On Mon, May 25, 2015 at 07:07:14PM +0000, James Bottomley wrote:
> > > > On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
> > > > > On Mon, May 25, 2015 at 12:55:17PM +0200, Paul Bolle wrote:
> > > > > > On Fri, 2015-05-22 at 14:43 -0700, josh@joshtriplett.org wrote:
> > > > > > > Ideally, someone should teach Kconfig to handle recursive dependencies,
> > > > > > 
> > > > > > I'm probably reading too much in this remark, but how should it handle
> > > > > > that other than returning an error because the configuration it's fed
> > > > > > makes it run in circles?
> > > > > 
> > > > > I don't mean cyclic dependencies (for which Kconfig should just report
> > > > > an error, ideally including the full list of symbols forming the cycle).
> > > > > 
> > > > > I mean that Kconfig should do recursive dependency resolution.  If B
> > > > > depends on A, and C depends on B, I should be able to turn on C
> > > > > directly and have B and A enabled.
> > > > 
> > > > That's really hard in practise you have to make any symbol that selects
> > > > something depend on the dependencies of the selected symbol.  You can't
> > > > do this without involving a SAT solver.  A guy promised to do this a
> > > > couple of years ago, but the patches never materialised.  However, they
> > > > may exist somewhere if someone wants to take a look at completing it.
> > > 
> > > You can't do this in the completely general case without a SAT solver.
> > > However, I think it's possible to help the user a bit more than than
> > > Kconfig currently does without introducing a general dependency solver.
> > 
> > Well the logically simplest way of doing that it to require that a
> > selected symbol can have no dependencies (but may select others) and to
> > make this what Kconfig enforces ... of course, our current Kconfig tree
> > violates this all over the place.
> 
> Or enforce that it has no disabled dependencies.

That's what doesn't work: once you depend on a symbol that selects
something else, you have to evaluate the satisfiability condition again
recursively ... and that's a SAT solver.  Unfortunately, you need either
a heuristic that makes the logic chains simple or resign yourself to
doing it properly.

> > > In particular, it'd be nice to have an easy way to see at a glance
> > > "can't enable C because it depends on B", together with an easy way to
> > > get to B to enable it to get to C.  User-guided dependency resolution
> > > seems like an improvement over no dependency resolution.
> > 
> > Sure, but it's mostly people like us doing it and find . -name Kconfig\*
> > -exec grep -3 <symbol> {} /dev/null \; usually does the trick for me.
> 
> That's not particularly convenient from the middle of menuconfig when
> configuring a kernel.  It'd be nice to be able to navigate in one step
> from a symbol to its dependencies within the menuconfig interface.

Well, it works for me but, sure, do something you prefer ... I use make
config rather than menuconfig anyway.

James

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Geert Uytterhoeven]

On Mon, May 25, 2015 at 11:29 PM, James Bottomley <jbottomley@odin.com> wrote:
> Sure, but it's mostly people like us doing it and find . -name Kconfig\*
> -exec grep -3 <symbol> {} /dev/null \; usually does the trick for me.

git grep -w3 <symbol> -- "*Kconf*"

And life becomes even easier with the following in your ~/.gitconfig:

[alias]
kgrep = !git grep $* -- \"*Kconf*\"

git kgrep -w3 <symbol>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds