From: Manu Abraham <abraham.manu@gmail.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: pci probe
Date: Wed, 16 May 2007 16:29:38 +0400 [thread overview]
Message-ID: <464AF932.9070008@gmail.com> (raw)
In-Reply-To: <20070516071851.GB19294@kroah.com>
Greg KH wrote:
> 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.)
This one sounds bad.
> - your driver will not work on any pci-hotplug type system (that
> includes expresscard and pccard and lots of high-end servers.
This doesn't matter
> - 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.
These also sound bad.
> 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 for the explanation.
Do you mean to have two PCIID tables ? But then that does mean 2 modules
don't you ? (i thought probe would be called once per module) Or you
mean to say use PCI_ANY_ID in the table to match multiple devices and
then allow probe to return a list of devices ?
Thanks,
Manu
next prev parent reply other threads:[~2007-05-16 12:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-14 19:03 pci probe Manu Abraham
2007-05-15 13:15 ` Manu Abraham
2007-05-16 7:18 ` Greg KH
2007-05-16 12:29 ` Manu Abraham [this message]
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=464AF932.9070008@gmail.com \
--to=abraham.manu@gmail.com \
--cc=greg@kroah.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 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.