On Wed, Feb 7, 2018 at 1:28 AM, Ulf Magnusson <ulfalizer@xxxxxxxxx> wrote: > On Tue, Feb 6, 2018 at 3:43 PM, Eugeniu Rosca <roscaeugeniu@xxxxxxxxx> wrote: >> Hi all, >> >> On Tue, Feb 6, 2018 at 1:00 PM, Petr Vorel <petr.vorel@xxxxxxxxx> wrote: >>> Hi, >>> >>>> Another possibility? >>> >>> >>>> Add [ ]: for each line to show the expression value. >>>> (but blank for 'n' for readability) >>> >>> >>>> Symbol: REGMAP_I2C [=y] >>>> Type : tristate >>>> Defined at drivers/base/regmap/Kconfig:19 >>>> Depends on: I2C [=y] >>>> Selected by: >>>> [y]: EEPROM_AT24 [=y] && I2C [=y] && SYSFS [=y] >>>> [ ]: NET_DSA_SMSC_LAN9303_I2C [=n] && NETDEVICES [=y] && >>>> HAVE_NET_DSA [=y] && NET_DSA [=n] && I2C [=y] >>>> [ ]: KEYBOARD_CAP11XX [=n] && !UML && INPUT [=y] && INPUT_KEYBOARD >>>> [=y] && OF [=y] && I2C [=y] >>>> [ ]: TOUCHSCREEN_AD7879_I2C [=n] && !UML && INPUT [=y] && >>>> INPUT_TOUCHSCREEN [=n] && TOUCHSCREEN_AD7879 [=n] && >>>> [ ]: TOUCHSCREEN_TSC2004 [=n] && !UML && INPUT [=y] && >>>> INPUT_TOUCHSCREEN [=n] && I2C [=y] >>>> [ ]: INPUT_DRV260X_HAPTICS [=n] && !UML && INPUT_MISC [=y] && >>>> INPUT [=y] && I2C [=y] && (GPIOLIB [=y] || COMPI >>>> [ ]: INPUT_DRV2665_HAPTICS [=n] && !UML && INPUT_MISC [=y] && >>>> INPUT [=y] && I2C [=y] >>>> [ ]: INPUT_DRV2667_HAPTICS [=n] && !UML && INPUT_MISC [=y] && >>>> INPUT [=y] && I2C [=y] >>>> [ ]: SERIAL_SC16IS7XX_I2C [=n] && TTY [=y] && HAS_IOMEM [=y] && >>>> SERIAL_SC16IS7XX [=n] && I2C [=y] >>>> [ ]: I2C_MUX_LTC4306 [=n] && I2C [=y] && I2C_MUX [=y] >>>> [ ]: PINCTRL_MCP23S08 [=n] && PINCTRL [=y] && (SPI_MASTER [=y] || >>>> I2C [=y]) && (I2C [=y] || I2C [=y]=n) && I2C >>>> [ ]: GPIO_TS4900 [=n] && GPIOLIB [=y] && I2C [=y] && (SOC_IMX6 || >>>> COMPILE_TEST [=n]) >>>> [ ]: BATTERY_MAX17042 [=n] && POWER_SUPPLY [=y] && I2C [=y] >>>> [ ]: CHARGER_BQ25890 [=n] && POWER_SUPPLY [=y] && I2C [=y] && >>>> (GPIOLIB [=y] || COMPILE_TEST [=n]) >>>> [ ]: CHARGER_SMB347 [=n] && POWER_SUPPLY [=y] && I2C [=y] >>>> [ ]: CHARGER_RT9455 [=n] && POWER_SUPPLY [=y] && I2C [=y] && >>>> (GPIOLIB [=y] || COMPILE_TEST [=n]) >>>> [y]: SENSORS_LTC2945 [=y] && HWMON [=y] && I2C [=y] >>>> ... >>> >>> >>> This looks best variant to me. >> >> I like this approach too. The only downside I see for not doing >> explicit classification/break-down is that you will still have to >> scroll through 212 Selected-by entries of REGMAP_I2C to identify the 9 >> ones which evaluate to =y or =m. >> Fortunately, there are not so many symbols like REGMAP_I2C, so it will >> most lilkely not bother anybody. >> I'll make a sketch/proposal in the next days. But if anybody is >> impatient about implementing this himself, I don't mind. >> >> Thanks for your replies. >> >> Best regards, >> Eugeniu. > > Yeah, I like the grouping feature too, with the m/y selects listed > separately from the n selects. That'd be helpful both when trying to > figure why a particular symbol is being selected, and when trying to > figure why it isn't being selected, both of which are probably pretty > common. > > Cheers, > Ulf Though I guess it wouldn't matter for the not-selected case. Many cases where it'd be helpful still I think. Cheers, Ulf -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
