linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Scott Wood <scottwood@freescale.com>
Cc: "Igal.Liberman" <igal.liberman@freescale.com>,
	linuxppc-dev@lists.ozlabs.org, mturquette@linaro.org
Subject: Re: [v4] clk: qoriq: Add support for the FMan clock
Date: Wed, 6 May 2015 15:25:08 -0700	[thread overview]
Message-ID: <20150506222508.GA21794@codeaurora.org> (raw)
In-Reply-To: <1430897672.16357.279.camel@freescale.com>

On 05/06, Scott Wood wrote:
> On Wed, 2015-05-06 at 00:02 -0700, Stephen Boyd wrote:
> > On 04/16, Igal.Liberman wrote:
> > > +static int get_fm_clk_idx(int fm_id, int *fm_clk_idx)
> > > +{
> > > +	struct ccsr_guts __iomem *guts_regs = NULL;
> > 
> > Unnecessary initialization to NULL. Also, marking a structure as
> > __iomem is odd. Why do we need to use a struct to figure out
> > offsets for registers? Why not just use #defines? That would
> > probably also make it easy to avoid the asm include here.
> 
> Using a struct for registers is quite common:
> scott@snotra:~/fsl/git/linux/upstream$ git grep struct|grep __iomem|wc -l
> 3005

$ git grep -E 'struct \w+ __iomem' | wc -l
2212

That's slightly inflated, but ok.

Within drivers/clk there aren't any though, hence my apprehension

$ git grep -E 'struct \w+ __iomem' -- drivers/clk/ | wc -l
0

> 
> It provides type-safety, and makes accessing the registers more natural.

Sure, we can leave the struct as is, but to make this compile on
ARM we need to figure something out. Move the struct definition
into include/linux/platform_data/ perhaps?

> 
> > > +	struct device_node *guts;
> > > +	uint32_t reg = 0;
> > 
> > s/uint32_t/u32/
> 
> Why?

This matches the rest of the file except for one instance of
uint32_t. I googled it and found [1], perhaps that will help.

> 
> > Also unnecessary initialization.
> 
> Given the if/else if/else if/... nature of how reg is initialized, this
> seems like a useful and harmless way of making behavior predictable if
> there is a bug.
> 

If there's a possibility of a bug due to missed initialization
perhaps it's a sign the code is too complicated and should be
broken down into smaller functions. For example, this function
could be rewritten to have a match table with function pointers
that return the fm_clk_idx.

[1] http://lkml.iu.edu/hypermail/linux/kernel/1101.3/02176.html

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2015-05-06 22:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-16 12:05 [v4] clk: qoriq: Add support for the FMan clock Igal.Liberman
2015-05-06  7:02 ` Stephen Boyd
2015-05-06  7:34   ` Scott Wood
2015-05-06 22:25     ` Stephen Boyd [this message]
2015-05-06 23:01       ` Scott Wood

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=20150506222508.GA21794@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=igal.liberman@freescale.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mturquette@linaro.org \
    --cc=scottwood@freescale.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 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).