From: emilio@elopez.com.ar (Emilio López)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/5] clk: sun6i: Protect CPU clock
Date: Mon, 24 Feb 2014 21:30:05 -0300 [thread overview]
Message-ID: <530BE40D.8080506@elopez.com.ar> (raw)
In-Reply-To: <20140225000154.GR21483@n2100.arm.linux.org.uk>
Hi Russell,
El 24/02/14 21:01, Russell King - ARM Linux escribi?:
> Hi Emilio.
>
> On Mon, Feb 24, 2014 at 08:38:44PM -0300, Emilio L?pez wrote:
>> Why is this so? Can't a clock be left enabled while nobody has a
>> reference to it? I have looked around in Documentation/ (rather quickly
>> I must say) and have not found any explicit mention that it is required
>> to keep a reference to the clock while it's enabled. I'd appreciate it
>> if you could explain this a bit more verbosely or point me to the
>> relevant documents.
>
> First up, if you have a requirement that a clock be enabled, then is it
> not unreasonable to ensure that the clock is referenced?
I was under the impression that the reference count was orthogonal to
the clock status, but after getting that clarified, I can see your point.
> Secondly, what if we have code which scans the clocks in the system,
> shutting down those leaf clocks which appear to be unreferenced?
Indeed, that would break things.
> Thirdly, the API (as I designed it) says so:
>
> /**
> * clk_put - "free" the clock source
> * @clk: clock source
> *
> * Note: drivers must ensure that all clk_enable calls made on this
> * clock source are balanced by clk_disable calls prior to calling
> * this function.
> *
> * clk_put should not be called from within interrupt context.
> */
> void clk_put(struct clk *clk);
>
> which has been there since the API was first created - it's part of the
> contract between drivers using the API and implementers creating something
> which conforms to the API - which today means CCF.
That's enough of a reason on its own :) I should have checked clk.h
> The intention here is that while there are any users holding a clk_get()
> reference on a clock, the clock is assumed to be required for some
> device, and the struct clk may not be kfree'd, nor may its state be
> changed in an unpredictable way to those drivers holding a reference
> to it.
I understand now, thanks for the insight. I'll talk with Maxime and get
this sorted out.
As a side note, should drivers/base/power/clock_ops.c be fixed too? I
have added Rafael to Cc.
Cheers,
Emilio
WARNING: multiple messages have this Message-ID (diff)
From: "Emilio López" <emilio-0Z03zUJReD5OxF6Tv1QG9Q@public.gmane.org>
To: Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mike Turquette
<mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Dan Williams
<dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
rjw-KKrjLPT3xs0@public.gmane.org
Subject: Re: [PATCH 1/5] clk: sun6i: Protect CPU clock
Date: Mon, 24 Feb 2014 21:30:05 -0300 [thread overview]
Message-ID: <530BE40D.8080506@elopez.com.ar> (raw)
In-Reply-To: <20140225000154.GR21483-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
Hi Russell,
El 24/02/14 21:01, Russell King - ARM Linux escribió:
> Hi Emilio.
>
> On Mon, Feb 24, 2014 at 08:38:44PM -0300, Emilio López wrote:
>> Why is this so? Can't a clock be left enabled while nobody has a
>> reference to it? I have looked around in Documentation/ (rather quickly
>> I must say) and have not found any explicit mention that it is required
>> to keep a reference to the clock while it's enabled. I'd appreciate it
>> if you could explain this a bit more verbosely or point me to the
>> relevant documents.
>
> First up, if you have a requirement that a clock be enabled, then is it
> not unreasonable to ensure that the clock is referenced?
I was under the impression that the reference count was orthogonal to
the clock status, but after getting that clarified, I can see your point.
> Secondly, what if we have code which scans the clocks in the system,
> shutting down those leaf clocks which appear to be unreferenced?
Indeed, that would break things.
> Thirdly, the API (as I designed it) says so:
>
> /**
> * clk_put - "free" the clock source
> * @clk: clock source
> *
> * Note: drivers must ensure that all clk_enable calls made on this
> * clock source are balanced by clk_disable calls prior to calling
> * this function.
> *
> * clk_put should not be called from within interrupt context.
> */
> void clk_put(struct clk *clk);
>
> which has been there since the API was first created - it's part of the
> contract between drivers using the API and implementers creating something
> which conforms to the API - which today means CCF.
That's enough of a reason on its own :) I should have checked clk.h
> The intention here is that while there are any users holding a clk_get()
> reference on a clock, the clock is assumed to be required for some
> device, and the struct clk may not be kfree'd, nor may its state be
> changed in an unpredictable way to those drivers holding a reference
> to it.
I understand now, thanks for the insight. I'll talk with Maxime and get
this sorted out.
As a side note, should drivers/base/power/clock_ops.c be fixed too? I
have added Rafael to Cc.
Cheers,
Emilio
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
WARNING: multiple messages have this Message-ID (diff)
From: "Emilio López" <emilio@elopez.com.ar>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>,
devicetree@vger.kernel.org,
Mike Turquette <mturquette@linaro.org>,
Vinod Koul <vinod.koul@intel.com>,
linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com,
dmaengine@vger.kernel.org,
Dan Williams <dan.j.williams@intel.com>,
linux-arm-kernel@lists.infradead.org, rjw@sisk.pl
Subject: Re: [PATCH 1/5] clk: sun6i: Protect CPU clock
Date: Mon, 24 Feb 2014 21:30:05 -0300 [thread overview]
Message-ID: <530BE40D.8080506@elopez.com.ar> (raw)
In-Reply-To: <20140225000154.GR21483@n2100.arm.linux.org.uk>
Hi Russell,
El 24/02/14 21:01, Russell King - ARM Linux escribió:
> Hi Emilio.
>
> On Mon, Feb 24, 2014 at 08:38:44PM -0300, Emilio López wrote:
>> Why is this so? Can't a clock be left enabled while nobody has a
>> reference to it? I have looked around in Documentation/ (rather quickly
>> I must say) and have not found any explicit mention that it is required
>> to keep a reference to the clock while it's enabled. I'd appreciate it
>> if you could explain this a bit more verbosely or point me to the
>> relevant documents.
>
> First up, if you have a requirement that a clock be enabled, then is it
> not unreasonable to ensure that the clock is referenced?
I was under the impression that the reference count was orthogonal to
the clock status, but after getting that clarified, I can see your point.
> Secondly, what if we have code which scans the clocks in the system,
> shutting down those leaf clocks which appear to be unreferenced?
Indeed, that would break things.
> Thirdly, the API (as I designed it) says so:
>
> /**
> * clk_put - "free" the clock source
> * @clk: clock source
> *
> * Note: drivers must ensure that all clk_enable calls made on this
> * clock source are balanced by clk_disable calls prior to calling
> * this function.
> *
> * clk_put should not be called from within interrupt context.
> */
> void clk_put(struct clk *clk);
>
> which has been there since the API was first created - it's part of the
> contract between drivers using the API and implementers creating something
> which conforms to the API - which today means CCF.
That's enough of a reason on its own :) I should have checked clk.h
> The intention here is that while there are any users holding a clk_get()
> reference on a clock, the clock is assumed to be required for some
> device, and the struct clk may not be kfree'd, nor may its state be
> changed in an unpredictable way to those drivers holding a reference
> to it.
I understand now, thanks for the insight. I'll talk with Maxime and get
this sorted out.
As a side note, should drivers/base/power/clock_ops.c be fixed too? I
have added Rafael to Cc.
Cheers,
Emilio
next prev parent reply other threads:[~2014-02-25 0:30 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-24 16:22 [PATCH 0/5] Add support for the Allwinner A31 DMA Controller Maxime Ripard
2014-02-24 16:22 ` Maxime Ripard
2014-02-24 16:22 ` Maxime Ripard
2014-02-24 16:22 ` [PATCH 1/5] clk: sun6i: Protect CPU clock Maxime Ripard
2014-02-24 16:22 ` Maxime Ripard
2014-02-24 16:22 ` Maxime Ripard
2014-02-24 16:30 ` Russell King - ARM Linux
2014-02-24 16:30 ` Russell King - ARM Linux
2014-02-24 16:30 ` Russell King - ARM Linux
2014-02-24 23:38 ` Emilio López
2014-02-24 23:38 ` Emilio López
2014-02-24 23:38 ` Emilio López
2014-02-25 0:01 ` Russell King - ARM Linux
2014-02-25 0:01 ` Russell King - ARM Linux
2014-02-25 0:01 ` Russell King - ARM Linux
2014-02-25 0:30 ` Emilio López [this message]
2014-02-25 0:30 ` Emilio López
2014-02-25 0:30 ` Emilio López
2014-02-24 16:22 ` [PATCH 2/5] clk: sun6i: Reparent AHB clock on PLL6 Maxime Ripard
2014-02-24 16:22 ` Maxime Ripard
2014-02-24 16:22 ` Maxime Ripard
2014-02-24 16:22 ` [PATCH 3/5] clk: sun6i: Protect SDRAM gating bit Maxime Ripard
2014-02-24 16:22 ` Maxime Ripard
2014-02-24 16:22 ` Maxime Ripard
2014-02-24 16:22 ` [PATCH 4/5] DMA: sun6i: Add driver for the Allwinner A31 DMA controller Maxime Ripard
2014-02-24 16:22 ` Maxime Ripard
2014-02-24 16:22 ` Maxime Ripard
2014-02-25 11:28 ` Andy Shevchenko
2014-02-25 11:28 ` Andy Shevchenko
2014-02-25 11:28 ` Andy Shevchenko
2014-02-28 10:36 ` Maxime Ripard
2014-02-28 10:36 ` Maxime Ripard
2014-02-28 10:36 ` Maxime Ripard
2014-02-28 13:33 ` Andy Shevchenko
2014-02-28 13:33 ` Andy Shevchenko
2014-02-28 13:33 ` Andy Shevchenko
2014-02-28 14:27 ` Maxime Ripard
2014-02-28 14:27 ` Maxime Ripard
2014-02-28 14:27 ` Maxime Ripard
2014-02-24 16:22 ` [PATCH 5/5] ARM: sun6i: dt: Add A31 DMA controller to DTSI Maxime Ripard
2014-02-24 16:22 ` Maxime Ripard
2014-02-24 16:22 ` Maxime Ripard
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=530BE40D.8080506@elopez.com.ar \
--to=emilio@elopez.com.ar \
--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 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.