From: Vladimir Zapolskiy <vz@mleia.com>
To: Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@codeaurora.org>
Cc: linux-clk@vger.kernel.org
Subject: [PATCH 2/3] clk: simplify array allocation of clock parents for lookup
Date: Thu, 7 Jan 2016 05:16:07 +0200 [thread overview]
Message-ID: <1452136568-478-3-git-send-email-vz@mleia.com> (raw)
In-Reply-To: <1452136568-478-1-git-send-email-vz@mleia.com>
The change intends to centralize allocation of clock's clk_core
parents array on clock registration, originally is done from multiple
places:
* __clk_init()
* __clk_init_parent()
* clk_fetch_parent_index()
The original approach historically was needed, but at the moment
all assumptions supporting it are wrong:
1) GFP_KERNEL heap is available at the time of a clock registration,
for example it is used to dynamically allocate struct clk_core,
clock name and clock parent names, if allocation fails, return
-ENOMEM as usual instead of repeating attempts to allocate the
array in future,
2) due to the layering scheme clk_core parents can not be defined
statically by the drivers, instead the drivers provide string
arrays of clock parent names and clock parents for a lookup array
are always obtained from that data.
To ensure that there is no need to check for allocated status of the
parent lookup table and/or allocate the table from other places within
the common clock framework, don't register a clock, if there is no
enough memory.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/clk/clk.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 129ac0a..2fb0dae 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2371,27 +2371,25 @@ static int __clk_init(struct device *dev, struct clk *clk_user)
/*
* Allocate an array of struct clk *'s to avoid unnecessary string
- * look-ups of clk's possible parents. This can fail for clocks passed
- * in to clk_init during early boot; thus any access to core->parents[]
- * must always check for a NULL pointer and try to populate it if
- * necessary.
- *
- * If core->parents is not NULL we skip this entire block. This allows
- * for clock drivers to statically initialize core->parents.
+ * look-ups of clk's possible parents.
*/
- if (core->num_parents > 1 && !core->parents) {
+ if (core->num_parents > 1) {
core->parents = kcalloc(core->num_parents, sizeof(struct clk *),
GFP_KERNEL);
+ if (!core->parents) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
/*
* clk_core_lookup returns NULL for parents that have not been
* clk_init'd; thus any access to clk->parents[] must check
* for a NULL pointer. We can always perform lazy lookups for
* missing parents later on.
*/
- if (core->parents)
- for (i = 0; i < core->num_parents; i++)
- core->parents[i] =
- clk_core_lookup(core->parent_names[i]);
+ for (i = 0; i < core->num_parents; i++)
+ core->parents[i] =
+ clk_core_lookup(core->parent_names[i]);
}
core->parent = __clk_init_parent(core);
--
2.1.4
next prev parent reply other threads:[~2016-01-07 3:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-07 3:16 [PATCH 0/3] clk: remove dead code allocations of parent lookup tables Vladimir Zapolskiy
2016-01-07 3:16 ` [PATCH 1/3] clk: don't fetch parent index for non multi-parent clocks Vladimir Zapolskiy
2016-01-07 3:16 ` Vladimir Zapolskiy [this message]
2016-01-07 3:16 ` [PATCH 3/3] clk: remove redundant clock parents lookup table allocations Vladimir Zapolskiy
2016-01-07 9:00 ` Masahiro Yamada
2016-01-07 10:44 ` Vladimir Zapolskiy
2016-01-07 11:33 ` Masahiro Yamada
2016-01-07 13:45 ` Vladimir Zapolskiy
2016-01-08 0:33 ` [PATCH 0/3] clk: remove dead code allocations of parent lookup tables Vladimir Zapolskiy
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=1452136568-478-3-git-send-email-vz@mleia.com \
--to=vz@mleia.com \
--cc=linux-clk@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=sboyd@codeaurora.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