linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: p.zabel@pengutronix.de (Philipp Zabel)
To: linux-arm-kernel@lists.infradead.org
Subject: Why do we need reset_control_get_optional() ?
Date: Thu, 28 Jul 2016 11:43:00 +0200	[thread overview]
Message-ID: <1469698980.12835.18.camel@pengutronix.de> (raw)
In-Reply-To: <CAK7LNAQnitMMp5wMXXvVeS-UFF=Fo9m=M1hL=5f4=RF8JYCnGg@mail.gmail.com>

Am Samstag, den 23.07.2016, 20:22 +0900 schrieb Masahiro Yamada:
> Hi.
> 
> 
> Now the reset subsystem provides
> a bunch of reset_control_get variants.
> 
> I am still wondering why we need to have _optional ones.
> 
> As far as I see, the difference is WARN_ON(1)
> when CONFIG_RESET_CONTROLLER is not defined.
> 
> 
> 
> [1] When the reset is mandatory,
> the code of the reset consumer is probably like follows:
> 
>   rst = devm_reset_control_get(dev, NULL);
>   if (IS_ERR(rst)) {
>           dev_err(dev, "failed to get reset\n");
>           return PTR_ERR(rst);
>   }
> 
>   ret = reset_control_deassert(rst);
>   if (ret) {
>           dev_err(dev, "failed to deassert reset\n");
>           return ret;
>   }
> 
>    ...
> 
> 
> 
> [2] When the reset is optional,
>   the code should be something like follows:
> 
>    rst = devm_reset_control_get(dev, NULL);
>    if (ERR_PTR(rst) == -EPROBE_DEFER)
>            return -EPROBE_DEFER;
> 
>    /* deassert reset if it is available */
>    if (!IS_ERR(rst)) {
>            ret = reset_control_deassert(rst);
>            if (ret) {
>                   dev_err(dev, "failed to deassert reset\n");
>                   return ret;
>            }
>     }
> 
> 
> 
> 
> What I mean is, we can write a driver in either way
> without using the _optional one.
> 
> No need to call WARN_ON(1).
> 
> 
> What does _optional buy us?

It will complain loudly with a backtrace if a driver requests a
non-optional reset on a kernel/platform with the reset framework
disabled.

> One more thing.
> WARN_ON(1) is only useful on run-time,
> but run-time test is more expensive than compile-time test.
> 
> If a driver really needs reset control,
> it should not be complied without CONFIG_RESET_CONTROLLER.
> So, the driver should have "depends on RESET_CONTROLLER" in Kconfig.

If we do that, we can't compile test those drivers anymore in
configurations without RESET_CONTROLLER enabled.

[...]
> 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
?

regards
Philipp

  reply	other threads:[~2016-07-28  9:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-23 11:22 Why do we need reset_control_get_optional() ? Masahiro Yamada
2016-07-28  9:43 ` Philipp Zabel [this message]
2016-07-28 10:09   ` Arnd Bergmann
2016-07-28 10:52     ` Masahiro Yamada
2016-07-28 11:00       ` Philipp Zabel
2016-08-05 15:50         ` Arnd Bergmann
2016-08-08 16:39           ` Philipp Zabel
2016-08-08 21:39             ` Arnd Bergmann
2016-08-16 14:36             ` Masahiro Yamada
2016-08-24  6:58               ` Masahiro Yamada
2016-08-24 12:30                 ` Philipp Zabel
2016-07-28 10:56     ` Philipp Zabel
2016-07-28 10:29   ` Masahiro Yamada
2016-07-29 13:08     ` Philipp Zabel
2016-07-30 20:13       ` Arnd Bergmann
2016-08-05  8:55         ` Philipp Zabel
2016-08-05 15:35           ` Arnd Bergmann
2016-08-08 17:29             ` Philipp Zabel
2016-08-16  9:41             ` Masahiro Yamada
2016-08-24 13:29               ` Philipp Zabel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1469698980.12835.18.camel@pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).