From: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Rajagopal Venkat
<rajagopal.venkat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH] clk: remove unreachable code
Date: Fri, 18 Jan 2013 09:43:13 -0800 [thread overview]
Message-ID: <20130118174313.3982.60050@quantum> (raw)
In-Reply-To: <CA+Z25wW=g+-Uo2DLpD=0ADjWTh5DKQb5ePPXR1tz0LXH3_b-xg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Quoting Rajagopal Venkat (2013-01-16 04:45:13)
> On 16 January 2013 04:15, Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > Quoting Rajagopal Venkat (2013-01-08 22:29:48)
> >> while reparenting a clock, NULL check is done for clock in
> >> consideration and its new parent. So re-check is not required.
> >> If done, else part becomes unreachable.
> >>
> >> Signed-off-by: Rajagopal Venkat <rajagopal.venkat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> ---
> >> drivers/clk/clk.c | 13 ++-----------
> >> 1 file changed, 2 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> >> index 251e45d..1c4097c 100644
> >> --- a/drivers/clk/clk.c
> >> +++ b/drivers/clk/clk.c
> >> @@ -1040,7 +1040,6 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent)
> >> {
> >> #ifdef CONFIG_COMMON_CLK_DEBUG
> >> struct dentry *d;
> >> - struct dentry *new_parent_d;
> >> #endif
> >>
> >> if (!clk || !new_parent)
> >> @@ -1048,22 +1047,14 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent)
> >>
> >> hlist_del(&clk->child_node);
> >>
> >> - if (new_parent)
> >> - hlist_add_head(&clk->child_node, &new_parent->children);
> >> - else
> >> - hlist_add_head(&clk->child_node, &clk_orphan_list);
> >> + hlist_add_head(&clk->child_node, &new_parent->children);
> >
> > Rajagopal,
> >
> > You found a bug, but not the right one :)
> >
> > This change would result in never moving a clock into the orphan list if
> > the parent is missing. The right thing to do is to allow the operation
> > to succeed and migrate this clock into the orphan list. In keeping
> > with the clk.h api we need to treat struct clk new_parent as an opaque
> > cookie and not care whether or not it is NULL.
> >
> Mike,
>
> The only path where __clk_reparent() can get new parent as NULL is from
> clk_set_parent() api. Tracing this path, here are the reasons why I submitted
> this patch.
>
> 1. The clk_set_parent() function takes new parent for granted and tries to
> access new_parent->rate when notifiers are registered,
> 2. For clocks with multiple parents, the __clk_set_parent() function also
> takes new parent for granted and tries to access parent name while finding
> the index of new parent from cached parent pointers.
>
> But if the design decision is to allow clock to be re-parented to orphan list
> when new parent is missing, I can provide the new working patch.
>
Rajagopal,
Yes, reparenting a clock to the orphan list should be supported. Let me
know if you are going to spin a new patch or not.
Thanks,
Mike
> > Untested patch below fixes the real bug:
> >
> >
> >
> > From a4d56e3ee51452366365749873710e16631e9de7 Mon Sep 17 00:00:00 2001
> > From: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Date: Tue, 15 Jan 2013 14:39:06 -0800
> > Subject: [PATCH] clk: allow re-parenting to NULL clks
> >
> > __clk_reparent presently bails early if the new parent of a clk is NULL.
> > This is wrong and prevents dynamically migrating clocks into the orphan
> > list. The fix is to remove the NULL pointer check for new_parent in
> > __clk_parent.
> >
> > Signed-off-by: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
> > drivers/clk/clk.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 593a2e4..f056230 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -1186,7 +1186,7 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent)
> > struct dentry *new_parent_d;
> > #endif
> >
> > - if (!clk || !new_parent)
> > + if (!clk)
> > return;
> >
> > hlist_del(&clk->child_node);
> > --
> > 1.7.10.4
> >
>
>
>
> --
> Regards,
> Rajagopal
prev parent reply other threads:[~2013-01-18 17:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-08 13:03 [PATCH] clk: remove unreachable code Rajagopal Venkat
2013-01-09 5:50 ` Tushar Behera
[not found] ` <50ED0517.5090907-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-01-09 5:58 ` Rajagopal Venkat
2013-01-09 6:29 ` Rajagopal Venkat
2013-01-09 6:35 ` Tushar Behera
[not found] ` <1357712988-22317-1-git-send-email-rajagopal.venkat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-01-15 22:45 ` Mike Turquette
2013-01-16 12:45 ` Rajagopal Venkat
[not found] ` <CA+Z25wW=g+-Uo2DLpD=0ADjWTh5DKQb5ePPXR1tz0LXH3_b-xg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-01-18 17:43 ` Mike Turquette [this message]
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=20130118174313.3982.60050@quantum \
--to=mturquette-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
--cc=linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=rajagopal.venkat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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;
as well as URLs for NNTP newsgroup(s).