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.
Thanks,
Manu
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 ?
Thanks,
Manu
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
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
On Wed, May 16, 2007 at 04:29:38PM +0400, Manu Abraham wrote:
> 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
Are you sure? PCI Hotplug is showing up in more places that people
realize...
> > - 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 ?
No, you can specify multiple devices in the same device id table, and
your driver will get called for all of the matching devices. You just
need to "bind" them together in your driver to be able to handle
everything properly. It shouldn't be that tough.
thanks,
greg k-h
On 5/30/07, Greg KH <[email protected]> wrote:
> On Wed, May 16, 2007 at 04:29:38PM +0400, Manu Abraham wrote:
> > 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
>
> Are you sure? PCI Hotplug is showing up in more places that people
> realize...
In case of video4linux and dvb, there are cx88 and saa7134 based
pcmcia devices available which show up as PCI devices, both of these
drivers enable the interrupts as soon as they're connected and there's
no need to access the device nodes for that.
Another point is that they're not hotplug aware, the driver end up in
an endless loop or crashes linux if someone unplugs the device (even
if it's not in use).
>
> > > - 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 ?
>
>
> No, you can specify multiple devices in the same device id table, and
> your driver will get called for all of the matching devices. You just
> need to "bind" them together in your driver to be able to handle
> everything properly. It shouldn't be that tough.
>
Uwe posted an example how to tie multiple functions of a device
together, there are quite a few ways how to solve that problem.
http://linuxtv.org/pipermail/linux-dvb/2007-June/018481.html
Markus
Hi,
Sorry for my late reply.
Greg KH wrote:
>>> - 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
>
> Are you sure? PCI Hotplug is showing up in more places that people
> realize...
The PCI bridges that we have for the mentioned use, does not support
Hotplugging at all and hence doesn't matter for those devices mentioned.
>>> - 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 ?
>
>
> No, you can specify multiple devices in the same device id table, and
> your driver will get called for all of the matching devices. You just
> need to "bind" them together in your driver to be able to handle
> everything properly. It shouldn't be that tough.
>
Will take a go at it.
I was using PCI_ANY_ID for the device id, so that should return all the
devices.
Thanks,
Manu