All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shuah Khan <shuah.khan@hp.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: dhowells@redhat.com, Joerg Roedel <joro@8bytes.org>,
	paulmck@linux.vnet.ibm.com, linasvepstas@gmail.com,
	davej@redhat.com, tglx@linutronix.de, mtk.manpages@gmail.com,
	iommu@lists.linux-foundation.org,
	LKML <linux-kernel@vger.kernel.org>,
	linux-pci@vger.kernel.org, shemminger@vyatta.com,
	jiang.liu@huawei.com, wangyijing@huawei.com, shuahkhan@gmail.com
Subject: Re: [PATCH 1/4] pci: Add PCI_BUS() and PCI_DEVID() interfaces to return bus number and device id
Date: Mon, 25 Feb 2013 09:37:25 -0700	[thread overview]
Message-ID: <1361810245.2975.14.camel@lorien2> (raw)
In-Reply-To: <CAErSpo6jY1bX9G59uz8Zt_pDJ4OoR=kJkGjNLYYRTrKVXM8+eg@mail.gmail.com>

On Wed, 2013-02-20 at 18:19 -0700, Bjorn Helgaas wrote:
> On Mon, Feb 11, 2013 at 4:00 PM, Shuah Khan <shuah.khan@hp.com> wrote:
> > pci defines PCI_DEVFN(), PCI_SLOT(), and PCI_FUNC() interfaces, however,
> > it doesn't have interfaces to return PCI bus and PCI device id. Drivers
> > (AMD IOMMU, and AER) implement module specific definitions for PCI_BUS()
> > and AMD_IOMMU driver also has a module specific interface to calculate PCI
> > device id from bus number and devfn.
> >
> > Add PCI_BUS and PCI_DEVID interfaces to return PCI bus number and PCI device
> > id respectively to avoid the need for duplicate definitions in other modules.
> > AER driver code and AMD IOMMU driver define PCI_BUS. AMD IOMMU driver defines
> > an interface to calculate device id from bus number, and devfn pair.
> >
> > Signed-off-by: Shuah Khan <shuah.khan@hp.com>
> > ---
> >  include/uapi/linux/pci.h |    4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/include/uapi/linux/pci.h b/include/uapi/linux/pci.h
> > index 3c292bc0..6b2c8b3 100644
> > --- a/include/uapi/linux/pci.h
> > +++ b/include/uapi/linux/pci.h
> > @@ -30,6 +30,10 @@
> >  #define PCI_DEVFN(slot, func)  ((((slot) & 0x1f) << 3) | ((func) & 0x07))
> >  #define PCI_SLOT(devfn)                (((devfn) >> 3) & 0x1f)
> >  #define PCI_FUNC(devfn)                ((devfn) & 0x07)
> > +#define PCI_DEVID(bus, devfn)  ((((u16)bus) << 8) | devfn)
> > +
> > +/* return bus from PCI devid = ((u16)bus_number) << 8) | devfn */
> > +#define PCI_BUS(x) (((x) >> 8) & 0xff)
> >
> >  /* Ioctls for /proc/bus/pci/X/Y nodes. */
> >  #define PCIIOC_BASE            ('P' << 24 | 'C' << 16 | 'I' << 8)
> 
> David, can you point me at a description of include/uapi ... what is
> there and why, and how we should decide what new things go in
> include/uapi/linux/pci.h as opposed to include/linux/pci.h?  Maybe
> there should be something in Documentation/?
> 
> I'm guessing it's something to do with being exported to userland, but
> I'm not sure the things in this patch (PCI_DEV_ID, PCI_BUS) are really
> exportable in the sense of being used for syscalls, etc.
> 

Bjorn,David,

Looks like the following thread answers some of the questions about when
this uapi export was done on the existing defines.

https://lkml.org/lkml/2011/7/28/198 

Sounds like the concern is that the older defines PCI_DEVFN, PCI_SLOT,
PCI_FUNC,  and PCI_DEVID could be exported, but not the new ones I
added. I could find any discussion on whether these four older defines
are exportable or the reasons for the export in the above thread.

So the question is if uapi/linux.pci.h isn't the right place, do you
have a recommendation on where they belong. The only alternative I can
think of is include/linux/pci.h. It makes functional and logical sense
to add the new defines to where the existing ones are defines. At least,
not knowing the details of the change that moved PCI_DEVFN etc. to
uapi/pci.h, that is my conclusion.

-- Shuah

  reply	other threads:[~2013-02-25 16:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-11 23:00 [PATCH 1/4] pci: Add PCI_BUS() and PCI_DEVID() interfaces to return bus number and device id Shuah Khan
2013-02-11 23:00 ` Shuah Khan
2013-02-21  1:19 ` Bjorn Helgaas
2013-02-21  1:19   ` Bjorn Helgaas
2013-02-25 16:37   ` Shuah Khan [this message]
2013-02-25 21:23     ` Bjorn Helgaas
2013-02-25 21:53       ` Shuah Khan
2013-02-27 21:48         ` Shuah Khan
2013-02-26  0:45   ` David Howells
2013-02-25 21:28 ` Bjorn Helgaas
2013-02-25 21:28   ` Bjorn Helgaas

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=1361810245.2975.14.camel@lorien2 \
    --to=shuah.khan@hp.com \
    --cc=bhelgaas@google.com \
    --cc=davej@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jiang.liu@huawei.com \
    --cc=joro@8bytes.org \
    --cc=linasvepstas@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=shemminger@vyatta.com \
    --cc=shuahkhan@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=wangyijing@huawei.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 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.