public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Walker <dwalker@codeaurora.org>
To: David Brown <davidb@codeaurora.org>
Cc: Steve Muckle <smuckle@codeaurora.org>,
	Stepan Moskovchenko <stepanm@codeaurora.org>,
	linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
Date: Fri, 11 Feb 2011 14:00:22 -0800	[thread overview]
Message-ID: <1297461622.4852.29.camel@m0nster> (raw)
In-Reply-To: <8yad3mykzks.fsf@huya.qualcomm.com>

On Fri, 2011-02-11 at 13:53 -0800, David Brown wrote:
> On Fri, Feb 11 2011, Daniel Walker wrote:
> 
> > On Fri, 2011-02-11 at 13:03 -0800, David Brown wrote:
> >> On Fri, Feb 11 2011, Steve Muckle wrote:
> 
> >> If they were used in more than one place, we could justify the
> >> definition, but in this case, the definition just obscures the code
> >> slightly.
> 
> Someone debugging it will look at the constant.  In fact, in general,
> the only person looking at this structure will want to know the value in
> the table.  Indirecting it through a pointer only serves to hide it from
> the person who wants to know the value.

Like I said in my example, people looking at the code won't always be
debugging.

> > A good example might be if all these constants are enumerated in a
> > header file, but aren't all used. In that case it would be fairly easy
> > to add a new resource without even know what the constant is just by
> > following the pattern.
> 
> This I definitely want to avoid.  I have seen header files with hundreds
> of thousands of register definitions, where only a few were used.

I think your thinking of stuff that's not properly grouped.

> > I think in general this series just makes this iommu code very much
> > 8660/8960 only code, but what about the potential next iteration of SoC
> > that uses very similar code to this with all new constants. So this
> > doesn't seem forward thinking to me.
> 
> The table would have the different addresses in it.  My point is that
> the resource table _is_ the definition of the addres.  Nothing is gained
> by inventing yet another name and putting that somewhere else.

In my example I showed you there is something to be gained by doing
this. As you said already there isn't must lost in doing it this way.

Daniel

-- 
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.



  reply	other threads:[~2011-02-11 22:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-11 20:28 [PATCH 1/3] msm: iommu: Create a Kconfig item for the IOMMU driver Stepan Moskovchenko
2011-02-11 20:28 ` [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets Stepan Moskovchenko
2011-02-11 20:42   ` Daniel Walker
2011-02-11 20:51     ` Steve Muckle
2011-02-11 20:58       ` Daniel Walker
2011-02-11 21:00         ` Steve Muckle
2011-02-11 21:03           ` Daniel Walker
2011-02-11 21:03       ` David Brown
2011-02-11 21:14         ` Daniel Walker
2011-02-11 21:53           ` David Brown
2011-02-11 22:00             ` Daniel Walker [this message]
2011-02-11 22:12   ` Daniel Walker
2011-02-11 22:37     ` David Brown
2011-02-11 22:47       ` Daniel Walker
2011-02-11 23:16         ` David Brown
2011-02-11 23:35           ` Daniel Walker
2011-02-11 20:28 ` [PATCH 3/3] msm: iommu: Enable IOMMU support for MSM8960 Stepan Moskovchenko
2011-02-11 20:38 ` [PATCH 1/3] msm: iommu: Create a Kconfig item for the IOMMU driver Daniel Walker
2011-02-15 19:35   ` David Brown
2011-02-15 19:49     ` Daniel Walker
2011-02-25  0:12       ` David Brown
2011-02-16  0:36     ` Daniel Walker

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=1297461622.4852.29.camel@m0nster \
    --to=dwalker@codeaurora.org \
    --cc=davidb@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smuckle@codeaurora.org \
    --cc=stepanm@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