Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1456955

Re: Why do we need reset_control_get_optional() ?

From Philipp Zabel <p.zabel@pengutronix.de>
Newsgroups linux.kernel
Subject Re: Why do we need reset_control_get_optional() ?
Date 2016-08-05 11:00 +0200
Message-ID <s2J8Z-5cv-3@gated-at.bofh.it> (permalink)
References <rY3i1-2br-15@gated-at.bofh.it> <rZQTn-4Zn-13@gated-at.bofh.it> <s0fI6-51U-17@gated-at.bofh.it> <s0ITM-79Q-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Am Samstag, den 30.07.2016, 22:13 +0200 schrieb Arnd Bergmann:
> 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?

Does the platform have to select RESET_FOO at all? Wouldn't it be enough
for RESET_FOO to have "default ARCH_FOO" ?

Currently ARCH_HAS_RESET_CONTROLLER is used to default y the
RESET_CONTROLLER symbol. Maybe we should add another
ARCH_REQUIRE_RESET_CONTROLLER and have that select RESET_CONTROLLER,
similarly to how it is done for GPIOLIB?

config ARCH_HAS_RESET_CONTROLLER
	bool
	help
	  Selecting this option from the architecture Kconfig enables
	  the RESET_CONTROLLER framework by default but does not select
	  it. Use it for architectures that still work without reset
	  controller support and thus allow the user to disable it.

config ARCH_REQUIRE_RESET_CONTROLLER
	bool
	select RESET_CONTROLLER
	help
	  Selecting this option from the architecture Kconfig selects
	  the RESET_CONTROLLER framework. Use it for architectures that
	  should not be built without the reset controller framework
	  enabled.

menuconfig RESET_CONTROLLER
        bool "Reset Controller Support"
        default ARCH_HAS_RESET_CONTROLLER || COMPILE_TEST
        help
          Generic Reset Controller support.

          This framework is designed to abstract reset handling of devices
          via GPIOs or SoC-internal reset controller modules.

          If unsure, say no.

The platforms could then select one of the ARCH_*_RESET_CONTROLLER
symbols and nobody would have to select RESET_CONTROLLER directly, for
example:

menuconfig ARCH_TEGRA                                                                                                                         
        bool "NVIDIA Tegra"
        depends on ARCH_MULTI_V7
        select ARCH_REQUIRE_GPIOLIB
        select ARCH_REQUIRE_RESET_CONTROLLER
        select ARCH_SUPPORTS_TRUSTED_FOUNDATIONS
        select ARM_AMBA
        select ARM_GIC
        select CLKSRC_MMIO
        select HAVE_ARM_SCU if SMP
        select HAVE_ARM_TWD if SMP
        select PINCTRL
        select PM_OPP
        select SOC_BUS
        help
          This enables support for NVIDIA Tegra based systems.

regards
Philipp

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: Why do we need reset_control_get_optional() ? Philipp Zabel <p.zabel@pengutronix.de> - 2016-07-28 11:50 +0200
  Re: Why do we need reset_control_get_optional() ? Arnd Bergmann <arnd@arndb.de> - 2016-07-28 12:20 +0200
    Re: Why do we need reset_control_get_optional() ? Philipp Zabel <p.zabel@pengutronix.de> - 2016-07-28 13:00 +0200
    Re: Why do we need reset_control_get_optional() ? Masahiro Yamada <yamada.masahiro@socionext.com> - 2016-07-28 13:00 +0200
      Re: Why do we need reset_control_get_optional() ? Philipp Zabel <p.zabel@pengutronix.de> - 2016-07-28 13:10 +0200
        Re: Why do we need reset_control_get_optional() ? Arnd Bergmann <arnd@arndb.de> - 2016-08-05 18:00 +0200
          Re: Why do we need reset_control_get_optional() ? Philipp Zabel <p.zabel@pengutronix.de> - 2016-08-08 18:40 +0200
            Re: Why do we need reset_control_get_optional() ? Arnd Bergmann <arnd@arndb.de> - 2016-08-08 23:50 +0200
  Re: Why do we need reset_control_get_optional() ? Masahiro Yamada <yamada.masahiro@socionext.com> - 2016-07-28 12:40 +0200
    Re: Why do we need reset_control_get_optional() ? Philipp Zabel <p.zabel@pengutronix.de> - 2016-07-29 15:10 +0200
      Re: Why do we need reset_control_get_optional() ? Arnd Bergmann <arnd@arndb.de> - 2016-07-30 22:20 +0200
        Re: Why do we need reset_control_get_optional() ? Philipp Zabel <p.zabel@pengutronix.de> - 2016-08-05 11:00 +0200
          Re: Why do we need reset_control_get_optional() ? Arnd Bergmann <arnd@arndb.de> - 2016-08-05 17:40 +0200
            Re: Why do we need reset_control_get_optional() ? Philipp Zabel <p.zabel@pengutronix.de> - 2016-08-08 19:30 +0200

csiph-web