From: Andrew Morton <akpm@linux-foundation.org>
To: Marc St-Jean <Marc_St-Jean@pmc-sierra.com>
Cc: linux-mips@linux-mips.org,
Brian Oostenbrink <Brian_Oostenbrink@pmc-sierra.com>,
Dan Doucette <Dan_Doucette@pmc-sierra.com>
Subject: Re: [PATCH 7/12] drivers: PMC MSP71xx GPIO char driver
Date: Tue, 19 Jun 2007 20:25:23 -0700 [thread overview]
Message-ID: <20070619202523.b0a2f9f0.akpm@linux-foundation.org> (raw)
In-Reply-To: <4678748B.8090403@pmc-sierra.com>
On Tue, 19 Jun 2007 17:27:55 -0700 Marc St-Jean <Marc_St-Jean@pmc-sierra.com> wrote:
> Andrew Morton wrote:
> > On Fri, 15 Jun 2007 14:46:03 -0600
> > Marc St-Jean <stjeanma@pmc-sierra.com> wrote:
> >
> > > [PATCH 7/12] drivers: PMC MSP71xx GPIO char driver
> > >
> > > Patch to add a GPIO char driver for the PMC-Sierra MSP71xx devices.
> >
>
> > > ...
> > >
> > > +/* Maps 'basic' pins to relative offset from 0 per register */
> > > +static int const MSP_GPIO_OFFSET[] = {
> > > + /* GPIO 0 and 1 on the first register */
> > > + 0, 0,
> > > + /* GPIO 2, 3, 4, and 5 on the second register */
> > > + 2, 2, 2, 2,
> > > + /* GPIO 6, 7, 8, and 9 on the third register */
> > > + 6, 6, 6, 6,
> > > + /* GPIO 10, 11, 12, 13, 14, and 15 on the fourth register */
> > > + 10, 10, 10, 10, 10, 10,
> > > +};
> >
> > This shouldn't be in a header file. Because each compilation unit which
> > includes this header will (potentially) get its own copy of the data.
> >
> > That includes any userspace apps which include this header(!)
>
> There are other drivers which use these macros irrespective of the char
> driver being compiled in or not. I can't move this to the driver .c file
> as all the macros will become useless.
In that case this storage should be placed into a separate .c file which
the others can link against. Creating a separate copy of this table
per-driver is bad practice.
> > inlined functions are preferred over macros. Only use macros when for some
> > reason you *must* use macros.
>
> Even for simple macros that have a single +, - or << ?
Sure, why not? There's rarely any reason to use macros.
> I thought there was an advantage to using macros, allowing the compiler to
> combine a series of simple macro calls into a single constant.
It will easily do that with inlines too.
next prev parent reply other threads:[~2007-06-20 3:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-20 0:27 [PATCH 7/12] drivers: PMC MSP71xx GPIO char driver Marc St-Jean
2007-06-20 3:25 ` Andrew Morton [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-06-20 22:54 Marc St-Jean
2007-06-15 20:46 Marc St-Jean
2007-06-19 21:12 ` Andrew Morton
2007-06-20 8:05 ` Ralf Baechle
2007-04-27 20:05 Marc St-Jean
2007-03-26 22:00 Marc St-Jean
2007-03-16 21:39 Marc St-Jean
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=20070619202523.b0a2f9f0.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Brian_Oostenbrink@pmc-sierra.com \
--cc=Dan_Doucette@pmc-sierra.com \
--cc=Marc_St-Jean@pmc-sierra.com \
--cc=linux-mips@linux-mips.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