From: Thierry Reding <thierry.reding@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, Stephen Warren <swarren@nvidia.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Stephen Warren <swarren@wwwdotorg.org>
Subject: Re: [PATCH 1/3] ASoC: alc5632: add an of_match table
Date: Fri, 4 Apr 2014 11:06:29 +0200 [thread overview]
Message-ID: <20140404090628.GD474@ulmo> (raw)
In-Reply-To: <20140331230517.GH2269@sirena.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1420 bytes --]
On Tue, Apr 01, 2014 at 12:05:17AM +0100, Mark Brown wrote:
> On Mon, Mar 31, 2014 at 04:53:57PM -0600, Stephen Warren wrote:
> > On 03/31/2014 04:45 PM, Mark Brown wrote:
>
> > > of_match_ptr() is supposed to avoid the warnings that the ifdefs fixed
> > > more prettily - I suspect you'll find that the ones that don't use it
> > > either predate of_match_ptr() or copied something that did.
>
> > I believe you either have the ifdef and the of_match_ptr(), or you have
> > neither. The use of of_match_ptr() is required when you wrap the
> > struct/array in an ifdef, so that the struct/array is only referenced
> > when it's declared.
>
> > I guess from your response you want the struct/array wrapped in an
> > ifdef, and to use of_match_ptr() when referencing it. I'll go ahead with
> > that; no need to reply if that's what you meant.
>
> No, what I'm saying is you shouldn't need the ifdef any more if you use
> of_match_ptr() and that's the more modern way to do things.
But I don't think that's the way it works. If you drop the #ifdef around
the struct of_device_id table and use of_match_ptr() when referencing it
then you'll get a warning from the compiler because the table is in fact
unreferenced. So all that of_match_ptr() really gives you is a way to
omit the:
#else
# define of_match_table NULL
So it doesn't really give you all that much in the end.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2014-04-04 9:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-31 18:38 [PATCH 1/3] ASoC: alc5632: add an of_match table Stephen Warren
2014-03-31 18:38 ` [PATCH 2/3] ASoC: tlv320aic23: " Stephen Warren
2014-04-01 11:45 ` Mark Brown
2014-03-31 18:38 ` [PATCH 3/3] ASoC: max98090: " Stephen Warren
2014-04-01 11:46 ` Mark Brown
2014-03-31 18:53 ` [PATCH 1/3] ASoC: alc5632: " Daniel Mack
2014-03-31 18:58 ` Stephen Warren
2014-03-31 19:23 ` Thierry Reding
2014-03-31 19:47 ` Stephen Warren
2014-03-31 22:45 ` Mark Brown
2014-03-31 22:53 ` Stephen Warren
2014-03-31 23:05 ` Mark Brown
2014-04-04 9:06 ` Thierry Reding [this message]
2014-04-01 11:40 ` Mark Brown
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=20140404090628.GD474@ulmo \
--to=thierry.reding@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=swarren@nvidia.com \
--cc=swarren@wwwdotorg.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.