[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3400649.NoVKUzu81R@wuerfel>
Date: Sat, 30 Jul 2016 22:13:54 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Philipp Zabel <p.zabel@...gutronix.de>
Cc: Masahiro Yamada <yamada.masahiro@...ionext.com>,
Axel Lin <axel.lin@...ics.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Hans de Goede <hdegoede@...hat.com>,
Maxime Ripard <maxime.ripard@...e-electrons.com>,
Lee Jones <lee.jones@...aro.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: Why do we need reset_control_get_optional() ?
On Friday, July 29, 2016 3:08:15 PM CEST Philipp Zabel wrote:
> Hi Masahiro,
>
> Am Donnerstag, den 28.07.2016, 19:29 +0900 schrieb Masahiro Yamada:
> [...]
> > However, I think the following makes more sense:
> >
> >
> > menuconfig RESET_CONTROLLER
> > bool "Reset Controller Support"
> > depends on (ARCH_HAS_RESET_CONTROLLER || COMPILE_TEST)
> > default y
> > help
> > Generic Reset Controller support.
>
> That looks sensible to me. You'll only have to enable the reset
> controller framework if either some enabled architecture has a reset
> controller (in which case you want the driver for it to be activated by
> default), or if you want to compile test some of the reset drivers.
This still doesn't let a platform 'select RESET_FOO', unless they
also select RESET_CONTROLLER and ARCH_HAS_RESET_CONTROLLER.
Why do we need to guard all drivers inside of two symbols?
Arnd
Powered by blists - more mailing lists