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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome