From: Greg KH <greg@kroah.com>
To: Manu Abraham <abraham.manu@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: pci probe
Date: Wed, 16 May 2007 00:18:51 -0700 [thread overview]
Message-ID: <20070516071851.GB19294@kroah.com> (raw)
In-Reply-To: <4649B270.8050002@gmail.com>
On Tue, May 15, 2007 at 05:15:28PM +0400, Manu Abraham wrote:
> Manu Abraham wrote:
> > Hi,
> >
> > I do have a device that's a multifunction device. Eventhough a MFD, it
> > just has one Interrupt which is shared by by a Configuration space for
> > each function. ie, INTA is shared between them functions.
> >
> > In such a case, i am wondering, (since pci_probe returns a pointer to
> > one PCI function alone and i need to use both the functions in one
> > module alone rather than using a module for each function and that the
> > functions are quite similar for them to be used in different modules,
> > such that a separate probe/ISR etc is used) whether using pci_get_device
> > would be a better alternative to do manual searching for the functions
> > in such a case.
> >
>
> Just figured out that pci_get_subsys() does work in a better. Looking at
> kernel sources all i find is just one single user of pci_get_subsys()
>
> building the code around pci_get_subsys(), does this have any negative
> impact ?
Yes:
- your device will not show up properly in sysfs (no
device/driver binding ability from userspace, no good
information so that udev can properly name the device, etc.)
- your driver will not work on any pci-hotplug type system (that
includes expresscard and pccard and lots of high-end servers.
- your driver will not be notified if the system is being
suspended or resumed or wanting to drop into a low power
state.
- another driver can bind to your device without you ever
knowing it.
So in short, use pci_probe and just handle the fact that you need to be
called for two PCI devices and bind to both of them. It shouldn't be
that hard...
thanks,
greg k-h
next prev parent reply other threads:[~2007-05-16 7:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-14 19:03 Manu Abraham
2007-05-15 13:15 ` Manu Abraham
2007-05-16 7:18 ` Greg KH [this message]
2007-05-16 12:29 ` Manu Abraham
2007-05-29 22:27 ` Greg KH
2007-06-07 20:00 ` Markus Rechberger
2007-06-13 7:39 ` Manu Abraham
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=20070516071851.GB19294@kroah.com \
--to=greg@kroah.com \
--cc=abraham.manu@gmail.com \
--cc=linux-kernel@vger.kernel.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
Powered by JetHome