From: Viresh Kumar <viresh.kumar@st.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"sshtylyov@mvista.com" <sshtylyov@mvista.com>,
spear-devel <spear-devel@list.st.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
"viresh.linux@gmail.com" <viresh.linux@gmail.com>,
"mturquette@linaro.org" <mturquette@linaro.org>,
"jgarzik@redhat.com" <jgarzik@redhat.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V2 4/9] ata/sata_mv: Remove conditional compilation of clk code
Date: Tue, 24 Apr 2012 14:00:43 +0530 [thread overview]
Message-ID: <4F9664B3.6040104@st.com> (raw)
In-Reply-To: <20120424082652.GQ24211@n2100.arm.linux.org.uk>
On 4/24/2012 1:56 PM, Russell King - ARM Linux wrote:
> Think about this case: if you don't have the means to control the clock
> inputs to a device (for example, you don't support the clk API on your
> CPU arch) then for the device to be functional, it must be supplied with
> all its necessary clocks. Therefore, the clock is already enabled. It
> makes sense for the clk API to stub-out to be completely transparent and
> non-error inducing to the driver.
>
> The problem comes with clk_get_rate(). I'd suggest merely returning zero
> for that in this case. If the clock rate is really required by a driver,
> then the clk API would need to be enabled.
Ok. Will do as suggested. Will include the patches i dropped earlier, where
i removed macros for clk_*().
--
viresh
WARNING: multiple messages have this Message-ID (diff)
From: viresh.kumar@st.com (Viresh Kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 4/9] ata/sata_mv: Remove conditional compilation of clk code
Date: Tue, 24 Apr 2012 14:00:43 +0530 [thread overview]
Message-ID: <4F9664B3.6040104@st.com> (raw)
In-Reply-To: <20120424082652.GQ24211@n2100.arm.linux.org.uk>
On 4/24/2012 1:56 PM, Russell King - ARM Linux wrote:
> Think about this case: if you don't have the means to control the clock
> inputs to a device (for example, you don't support the clk API on your
> CPU arch) then for the device to be functional, it must be supplied with
> all its necessary clocks. Therefore, the clock is already enabled. It
> makes sense for the clk API to stub-out to be completely transparent and
> non-error inducing to the driver.
>
> The problem comes with clk_get_rate(). I'd suggest merely returning zero
> for that in this case. If the clock rate is really required by a driver,
> then the clk API would need to be enabled.
Ok. Will do as suggested. Will include the patches i dropped earlier, where
i removed macros for clk_*().
--
viresh
next prev parent reply other threads:[~2012-04-24 8:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-24 7:04 [PATCH V2 4/9] ata/sata_mv: Remove conditional compilation of clk code Andrew Lunn
2012-04-24 7:04 ` Andrew Lunn
2012-04-24 7:05 ` Viresh Kumar
2012-04-24 7:05 ` Viresh Kumar
2012-04-24 7:26 ` Andrew Lunn
2012-04-24 7:26 ` Andrew Lunn
2012-04-24 7:42 ` Russell King - ARM Linux
2012-04-24 7:42 ` Russell King - ARM Linux
2012-04-24 7:58 ` Viresh Kumar
2012-04-24 7:58 ` Viresh Kumar
2012-04-24 8:26 ` Russell King - ARM Linux
2012-04-24 8:26 ` Russell King - ARM Linux
2012-04-24 8:30 ` Viresh Kumar [this message]
2012-04-24 8:30 ` Viresh Kumar
2012-04-24 12:04 ` Sergei Shtylyov
2012-04-24 12:04 ` Sergei Shtylyov
-- strict thread matches above, loose matches on Subject: below --
2012-04-24 5:56 [PATCH V2 0/9] clk: Add non CONFIG_HAVE_CLK routines Viresh Kumar
2012-04-24 5:56 ` [PATCH V2 4/9] ata/sata_mv: Remove conditional compilation of clk code Viresh Kumar
2012-04-24 5:56 ` Viresh Kumar
2012-04-24 5:56 ` Viresh Kumar
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=4F9664B3.6040104@st.com \
--to=viresh.kumar@st.com \
--cc=akpm@linux-foundation.org \
--cc=andrew@lunn.ch \
--cc=jgarzik@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mturquette@linaro.org \
--cc=spear-devel@list.st.com \
--cc=sshtylyov@mvista.com \
--cc=viresh.linux@gmail.com \
/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.