On Mon, 2017-01-16 at 10:46 +0000, Marcus Shawcroft wrote:
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
currently expressed using a Kconfig "depends" model rather than the
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
to solve the applications problem, all the dependencies get dragged
If you use "select", then the dependencies of that select are not
selected by default. This makes "select" a bit cumbersome and error
prone to use IMHO.
- 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
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'