On Wed, Feb 7, 2018 at 1:31 AM, Ulf Magnusson <ulfalizer@xxxxxxxxx> wrote: > 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 ...even there, it'd make it immediately obvious that the symbol isn't being selected. Cheers, Ulf "trigger-happy sender" -- 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
