On Mon, Feb 23, 2015 at 11:01:18PM +0100, Arnd Bergmann wrote: > On Saturday 21 February 2015 18:44:58 Mark Brown wrote: > > In that case a dependency seems wrong, I'd expect to see a select - it's > > a bit obscure to have to grovel around to figure out what magic options > > are needed to make things turn on and resets feel more like a utility > > thing than a control bus (which tend to be the things we depend on). > > Dunno, perhaps I'm wrong? > Mixing 'select' and 'depends on' causes recursive dependencies, and > there are already lots of drivers that do 'depends on RESET_CONTROLLER'. Well, perhaps that's the cleanup we should be doing then... one of the big problems with some of the other randconfig work there's been is that a lot of the patches just add dependencies without looking at if that makes sense. > Most users of this symbol seem to follow the strategy of selecting > RESET_CONTROLLER when a driver is there to provide the functionality, > but depending on it when a driver uses it. We are however a bit > inconsistent here and it would be nice to clean it up. Right, to me that feels the opposite way round to how we normally do things - the drivers for the subsystem normally depend on the subsystem (or are hidden by it). > In this particular patch, I'm just following what others do. > We should probably 'select ARCH_HAS_RESET_CONTROLLER' unconditionally > for ARM ARCH_MULTIPLATFORM, as it's a bit silly to select both > ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER from platform code. That does seem a bit odd. TBH I'm never sure that ARCH_HAS_ is that good an idea for the driver things, most of them can just as reasonably be used by off-SoC things.
Attachment:
signature.asc
Description: Digital signature
