From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Doug Anderson <dianders@chromium.org>,
Mike Turquette <mturquette@linaro.org>,
Heiko Stuebner <heiko@sntech.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] clk: Propagate prepare and enable when reparenting orphans
Date: Thu, 20 Nov 2014 10:06:33 +0000 [thread overview]
Message-ID: <20141120100633.GP4042@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20141120074514.GB30434@dtor-ws>
On Wed, Nov 19, 2014 at 11:45:14PM -0800, Dmitry Torokhov wrote:
> On Wed, Nov 19, 2014 at 09:15:41PM -0800, Doug Anderson wrote:
> > I will defer to your wisdom here. I agree that these are the two
> > primary solutions and I've picked one, but I have no idea which will
> > be more of a PITA in the long run.
> >
> > Note: I'm not sure that anyone expects EPROBE_DEFER to be returned
> > from a clk_enable() (do they?). It almost seems like the right answer
> > is to fail to allow anyone to clk_get() any clock that doesn't have a
> > path to root.
>
> EPROBE_DEFER only makes sense in driver's probe paths and so I would be
> very against adding it to clk_enable() which is called from many places
> in the kernel. If we decide to go with EPROBE_DEFER then returning it
> from clk_get() seems like a much better choice since it is normally
> called during probing.
Absolutely correct. EINVAL would be better for clk_prepare() since it
isn't something that can be recovered from by just retrying a bit later.
You're absolutely correct that EPROBE_DEFER has no business being returned
in any path other than a driver's probe function; it is not a user visible
error code, it is a special internal Linux error code which only the driver
model understands to mean "add this device to the deferred probe list and
try again a while later." Userspace, especially, should never see this
error code.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] clk: Propagate prepare and enable when reparenting orphans
Date: Thu, 20 Nov 2014 10:06:33 +0000 [thread overview]
Message-ID: <20141120100633.GP4042@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20141120074514.GB30434@dtor-ws>
On Wed, Nov 19, 2014 at 11:45:14PM -0800, Dmitry Torokhov wrote:
> On Wed, Nov 19, 2014 at 09:15:41PM -0800, Doug Anderson wrote:
> > I will defer to your wisdom here. I agree that these are the two
> > primary solutions and I've picked one, but I have no idea which will
> > be more of a PITA in the long run.
> >
> > Note: I'm not sure that anyone expects EPROBE_DEFER to be returned
> > from a clk_enable() (do they?). It almost seems like the right answer
> > is to fail to allow anyone to clk_get() any clock that doesn't have a
> > path to root.
>
> EPROBE_DEFER only makes sense in driver's probe paths and so I would be
> very against adding it to clk_enable() which is called from many places
> in the kernel. If we decide to go with EPROBE_DEFER then returning it
> from clk_get() seems like a much better choice since it is normally
> called during probing.
Absolutely correct. EINVAL would be better for clk_prepare() since it
isn't something that can be recovered from by just retrying a bit later.
You're absolutely correct that EPROBE_DEFER has no business being returned
in any path other than a driver's probe function; it is not a user visible
error code, it is a special internal Linux error code which only the driver
model understands to mean "add this device to the deferred probe list and
try again a while later." Userspace, especially, should never see this
error code.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2014-11-20 10:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-08 1:06 [PATCH v2] clk: Propagate prepare and enable when reparenting orphans Doug Anderson
2014-11-08 1:06 ` Doug Anderson
2014-11-20 2:30 ` Mike Turquette
2014-11-20 5:15 ` Doug Anderson
2014-11-20 5:15 ` Doug Anderson
2014-11-20 7:45 ` Dmitry Torokhov
2014-11-20 7:45 ` Dmitry Torokhov
2014-11-20 10:06 ` Russell King - ARM Linux [this message]
2014-11-20 10:06 ` Russell King - ARM Linux
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=20141120100633.GP4042@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=dianders@chromium.org \
--cc=dmitry.torokhov@gmail.com \
--cc=heiko@sntech.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mturquette@linaro.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 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.