Consistency in Kconfig organization, depends / select

Marcus Shawcroft <marcus.shawcroft@...>


I noticed this review fly by:

Which essentially adjusts a Kconfig to have an SPI driver Kconfig
explicitly select a GPIO driver when it needs the GPIO driver.

Many, perhaps most of the dependence relationships between drivers are
currently expressed using a Kconfig "depends" model rather than the
"select" model.

Over the last few months I've pondered the use of the "depends" model
rather than a "select" model. Superficially the "select" model has a
number of user facing advantages over the "depends" model, ones that
spring to mind are:
- As a user I can just enable the high level components/drivers I need
to solve the applications problem, all the dependencies get dragged in
- As a user I don;t need to dig around in Kconfig to figure out which
config options I need to first enable in order to get the actual
option I'm looking for to appear in the config menus (I've often found
myself having to do this :-(.

Looking in the drivers tree, there are many driver dependencies that
IMHO would give a better user config experience if we adopted a
selects model instead of the current depend model, for example:
- *sensor* -> I2C.
- console -> serial
- flash -> spi
- spi -> gpio
- ethernet -> random

What do folks think about adopting a more aggressive use of 'select'
instead of 'depend' above and beyond 9982



Join to automatically receive all group messages.