Why do we need reset_control_get_optional() ?

[arnd@arndb.de (Arnd Bergmann)]

On Thursday, July 28, 2016 11:43:00 AM CEST Philipp Zabel wrote:
> > I want to deprecate _optional variants in the following steps:
> > 
> > [1] Add "depends on RESET_CONTROLLER" to drivers
> >     for which reset_control is mandatory.
> > 
> >     We can find those driver easily by grepping
> >     the reference to non-optional reset_control_get().
> 
> Since we have the stubs, the RESET_CONTROLLER dependency is only at
> runtime, not at build time.
> 
> I think Arnd wanted to move this in the opposite direction and remove
> the configurable RESET_CONTROLLER symbol. Maybe we should let all
> drivers that currently request non-optional resets have:
>         depends on (ARCH_HAS_)RESET_CONTROLLER || COMPILE_TEST
> ?

There are various ways to improve the current situation.

I think it's important that a driver that has an optional
reset line behaves in exactly the same way whether the reset
subsystem is enabled or disabled when no reset line is
provided for a machine.

When a driver requires a reset line, we can either have a
build-time failure when the reset subsystem is disabled
(enforcing the Kconfig dependency), or cause a runtime
failure if either there is no reset line or the subsystem
is disabled.

In my experimental patch, I make the _optional functions
return NULL if no "resets" property is provided but return
an error if there are reset lines but the subsystem is
disabled, i.e. an optional reset must be used if it's in the
DT, but can be ignored otherwise.

	Arnd