linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
To: michael@ellerman.id.au
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] Introduce ppc_pci_flags accessors
Date: Wed, 10 Dec 2008 18:54:46 -0500	[thread overview]
Message-ID: <20081210185446.13e33cb2@zod.rchland.ibm.com> (raw)
In-Reply-To: <1228952788.7999.0.camel@localhost>

On Thu, 11 Dec 2008 10:46:28 +1100
Michael Ellerman <michael@ellerman.id.au> wrote:

> On Wed, 2008-12-10 at 14:11 -0500, Josh Boyer wrote:
> > Currently there are a number of platforms that open code access to
> > the ppc_pci_flags global variable.  However, that variable is not
> > present if CONFIG_PCI is not set, which can lead to a build break.
> > 
> > This introduces a number of accessor functions that are defined
> > to be empty in the case of CONFIG_PCI being disabled.  The
> > various platform files in the kernel are updated to use these.
> > 
> > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > 
> > ---
> > 
> > diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
> > index fa8b3b7..8f2c7ca 100644
> > --- a/arch/powerpc/include/asm/pci-bridge.h
> > +++ b/arch/powerpc/include/asm/pci-bridge.h
> > @@ -13,7 +13,6 @@
> >  
> >  struct device_node;
> >  
> > -extern unsigned int ppc_pci_flags;
> >  enum {
> >  	/* Force re-assigning all resources (ignore firmware
> >  	 * setup completely)
> > @@ -36,6 +35,16 @@ enum {
> >  	/* ... except for domain 0 */
> >  	PPC_PCI_COMPAT_DOMAIN_0		= 0x00000020,
> >  };
> > +#ifdef CONFIG_PCI
> > +extern unsigned int ppc_pci_flags;
> > +#define ppc_pci_set_flags(flags) ppc_pci_flags = (flags)
> > +#define ppc_pci_add_flags(flags) ppc_pci_flags |= (flags)
> > +#define ppc_pci_flag_is_set(flag) (ppc_pci_flags & (flag))
> > +#else
> > +#define ppc_pci_set_flags(flags) do {} while (0)
> > +#define ppc_pci_add_flags(flags) do {} while (0)
> > +#define ppc_pci_flag_is_set(flag) (0)
> > +#endif
> 
> I hate to be picky, but I don't see any reason why these shouldn't be
> static inlines.

There's a perfectly good reason.  I AM LAZY.

That aside, it doesn't matter to me either way.  If the general idea
seems fine and the naming of the functions is acceptable, I'd be happy
to respin.

josh

  reply	other threads:[~2008-12-10 23:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-10 19:11 [PATCH] Introduce ppc_pci_flags accessors Josh Boyer
2008-12-10 23:46 ` Michael Ellerman
2008-12-10 23:54   ` Josh Boyer [this message]
2008-12-11  0:04     ` Michael Ellerman
2008-12-11  0:47       ` Josh Boyer
2008-12-11  0:17     ` Trent Piepho
2008-12-11  0:53       ` Josh Boyer
2008-12-11 11:06         ` Benjamin Herrenschmidt

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=20081210185446.13e33cb2@zod.rchland.ibm.com \
    --to=jwboyer@linux.vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=michael@ellerman.id.au \
    /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).