mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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