From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: linux-kernel@vger.kernel.org,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Ramiro Oliveira <Ramiro.Oliveira@synopsys.com>
Subject: Re: [PATCH v1] reset: Make optional stuff optional for all users
Date: Mon, 03 Apr 2017 17:31:25 +0300 [thread overview]
Message-ID: <1491229885.708.106.camel@linux.intel.com> (raw)
In-Reply-To: <1491229671.2378.73.camel@pengutronix.de>
On Mon, 2017-04-03 at 16:27 +0200, Philipp Zabel wrote:
> Hi Andy,
>
> thank you for the patch.
>
> On Mon, 2017-04-03 at 15:26 +0300, Andy Shevchenko wrote:
> > There is Device Tree oriented check for optional resource. Of course
> > it will fail on non-DT platforms.
> >
> > Remove this check to make things optional for all users.
> >
> > Fixes: bb475230b8e5 ("reset: make optional functions really
> > optional")
> > Cc: Ramiro Oliveira <Ramiro.Oliveira@synopsys.com>
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> >
> > The reset framework is too Device Tree oriented, and who knows what
> > the logic was behind the commit which introduced devm_reset_*()
> > functions without thinking out of the DT box.
>
> At the time, there was nothing outside of the box to describe reset
> lines, and as far as I am aware there still isn't, so the devm_reset_*
> should behave as if the reset line is not specified in the non-DT
> case.
> Returning -EINVAL was reasonable in that case, before the API was
> changed to describe unavailable, optional reset controls as rstc =
> NULL.
Fair enough.
>
> > This commit fixes almost all Intel newest boards that have no
> > legacy
> > UART since UART driver started using this DT-centric framework.
>
> Is this is about 8250_dw.c? Unfortunately it sometimes takes a little
> while for me to get updated on the big picture, as I only get the
> actual
> reset driver and framework patches in my inbox. Usually I only see the
> reset consumer changes when I actively look for them.
Yes, 8250_dw.c in this case.
>
> But the fault in this case was is with me not considering all possible
> code paths influenced by commit bb475230b8e5, in the configurations
> that
> I can't test myself.
Understood.
>
> > drivers/reset/core.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/reset/core.c b/drivers/reset/core.c
> > index f1e5e65388bb..62314e663f29 100644
> > --- a/drivers/reset/core.c
> > +++ b/drivers/reset/core.c
> > @@ -331,9 +331,6 @@ struct reset_control
> > *__of_reset_control_get(struct device_node *node,
>
> Ideally, __of_reset_control_get would not be called at all in the non-
> DT
> case. I'll change that in the next round, but for now I'd prefer a
> small
> fix in place.
>
> > int rstc_id;
> > int ret;
> >
> > - if (!node)
> > - return ERR_PTR(-EINVAL);
> > -
>
> This should be
>
> if (!node)
> return optional ? NULL : ERR_PTR(-EINVAL);
>
> instead. Can you confirm this works for Intel boards with DW UART? I
> can
> fix it up when applying if you agree.
I don't think it worth to change. I specifically checked all of_* calls
in that function and they cope pretty nice with node == NULL.
So, I rather to go with my initial change.
Thanks for review!
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2017-04-03 14:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-03 12:26 [PATCH v1] reset: Make optional stuff optional for all users Andy Shevchenko
2017-04-03 14:27 ` Philipp Zabel
2017-04-03 14:31 ` Andy Shevchenko [this message]
2017-04-03 14:33 ` Shevchenko, Andriy
2017-04-03 15:09 ` Philipp Zabel
2017-04-03 15:23 ` Andy Shevchenko
2017-04-03 16:04 ` Philipp Zabel
2017-04-03 20:48 ` Andy Shevchenko
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=1491229885.708.106.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=Ramiro.Oliveira@synopsys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=p.zabel@pengutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.