From: tglx@linutronix.de (Thomas Gleixner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 3/4] clk: introduce the common clock framework
Date: Wed, 14 Mar 2012 22:28:15 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.02.1203142218320.2466@ionos> (raw)
In-Reply-To: <CAJOA=zMsCuZgmp1Hm0dq=EVoX6Zj62XQVqR=6GzDntSD5HnHzg@mail.gmail.com>
On Wed, 14 Mar 2012, Turquette, Mike wrote:
Could you folks please trim your replies? It's annoying to page down a
gazillion of lines to find the gist.
> On Wed, Mar 14, 2012 at 1:48 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >> Also, do you forsee needing hole in parent_names for any reason other
> >> than described above?
> >
> > I need it only for the case where a some values in the mux are marked as
> > reserved in the datasheet or we simply do not have the corresponding
> > clock in our tree (yet). We could also say that NULL pointers are not
> > allowed in parent arrays, but instead "orphan" or "dummy" should be
> > used. Then __clk_init should check for NULL pointers to make this clear.
>
> I've added a WARN in __clk_init if any entries in .parent_names are
> NULL. I think it best to populate it with "dummy", or maybe a
> platform-specific name if it helps you during development.
There is no guarantee that the selection of a parent can be mapped
linear to register values.
So the right way to deal with it is to have an array of valid names
with no holes and NULL pointers allowed and have a mapping from the
array index to the register value.
That makes the core code robust and allows to handle all corner cases
including reserved bits, not implemented clocks and weird register
layouts.
Thanks,
tglx
next prev parent reply other threads:[~2012-03-14 21:28 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-03 8:28 [PATCH v5 0/4] common clk framework Mike Turquette
2012-03-03 8:28 ` [PATCH v5 1/4] Documentation: common clk API Mike Turquette
2012-03-03 8:28 ` [PATCH v5 2/4] clk: Kconfig: add entry for HAVE_CLK_PREPARE Mike Turquette
2012-03-05 2:04 ` Richard Zhao
2012-03-05 19:46 ` Turquette, Mike
2012-03-03 8:29 ` [PATCH v5 3/4] clk: introduce the common clock framework Mike Turquette
2012-03-03 13:31 ` Sascha Hauer
2012-03-03 17:14 ` Turquette, Mike
2012-03-04 11:52 ` Sascha Hauer
2012-03-05 0:12 ` Turquette, Mike
2012-03-05 7:38 ` Sascha Hauer
2012-03-05 20:03 ` Turquette, Mike
2012-03-06 19:00 ` Sascha Hauer
2012-03-07 21:20 ` Turquette, Mike
2012-03-08 6:27 ` Andrew Lunn
2012-03-08 23:25 ` Sascha Hauer
2012-03-09 7:57 ` Andrew Lunn
2012-03-09 18:25 ` Turquette, Mike
2012-03-19 7:01 ` Shawn Guo
2012-03-19 11:22 ` Sascha Hauer
2012-03-09 18:18 ` Turquette, Mike
2012-03-09 0:51 ` Thomas Gleixner
2012-03-17 3:23 ` Saravana Kannan
2012-03-19 5:38 ` Shawn Guo
2012-03-19 7:42 ` Shawn Guo
2012-03-05 9:22 ` Richard Zhao
2012-03-14 2:03 ` Turquette, Mike
2012-03-13 11:24 ` Sascha Hauer
2012-03-13 23:43 ` Turquette, Mike
2012-03-14 8:48 ` Sascha Hauer
2012-03-14 20:47 ` Turquette, Mike
2012-03-14 21:28 ` Thomas Gleixner [this message]
2012-03-14 22:13 ` Turquette, Mike
2012-03-14 22:18 ` Thomas Gleixner
2012-03-03 8:29 ` [PATCH v5 4/4] clk: basic clock hardware types Mike Turquette
2012-03-04 14:26 ` Andrew Lunn
2012-03-04 14:35 ` Andrew Lunn
2012-03-05 0:15 ` Turquette, Mike
2012-03-04 17:42 ` Andrew Lunn
2012-03-05 0:30 ` Turquette, Mike
2012-03-05 8:48 ` Andrew Lunn
2012-03-05 9:29 ` Sascha Hauer
2012-03-05 10:17 ` Andrew Lunn
2012-03-09 23:38 ` Turquette, Mike
2012-03-04 20:33 ` [PATCH] clk: Fix compile errors in DEFINE_CLK_GATE Andrew Lunn
2012-03-05 0:31 ` Turquette, Mike
2012-03-07 21:20 ` [PATCH v5 4/4] clk: basic clock hardware types Sascha Hauer
2012-03-09 22:50 ` Turquette, Mike
2012-03-09 2:34 ` [PATCH v5 0/4] common clk framework Richard Zhao
2012-03-09 9:19 ` Sascha Hauer
2012-03-09 18:35 ` Turquette, Mike
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=alpine.LFD.2.02.1203142218320.2466@ionos \
--to=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox