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 -- 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
