Messages in this thread | | | Date | Wed, 4 Feb 2004 17:29:31 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: proper place for devfs_register_chrdev with pci_module_init |
| |
On Wed, 4 Feb 2004 odain2@mindspring.com wrote:
> On Wednesday February 4 2004 4:30 pm, you wrote: > > On Wed, 4 Feb 2004, Oliver Dain wrote: > > > I'm writing a char driver for a PCI card. Looking at examples of such > > > things I've found that most have a module_init like this: > > > > > > int foo_init(void) > > > { > > > /* stuff... */ > > > devfs_register_chrdev(...); > > > /* more stuff... */ > > > pci_module_init(...); > > > } > > > > > > This seems strange to me. The devfs_register_chrdev call will register > > > the module and cause it to be held in memory even if the associated > > > PCI device isn't present on the system. It seems like a better way > > > to do this is to have the init method just call pci_module_init(...) > > > and then in that method, after the PCI device has been initialized, call > > > devfs_register_chrdev to associate the driver with the device. That way > > > the kernel can unload the module if no such device is present, but if > > > the device is present (or if one appears via hotplug) the module will > > > be loaded and can then register itself. Will this work? Is there a > > > reason people don't do this? > > > > First! Fix your mailer. There wasn't a '\n' in the entire bunch > > of text above. Unix/Linux people use the [Enter] key and don't > > just auto-warp around the screen. > > > > > I'm not subscribed to the LKML so please CC me on any responses. > > > > > > Thanks, > > > Oliver > > > > Well the "standard way" to start up a module is to allocate > > resources for the module (like RAM), then register the module. > > > > Then if the device isn't found, it's unregistered and the resources > > freed. If the code to which you refer doesn't free its resources, > > including unregistering if the device isn't found, then it's a bug. > > > > Otherwise it doesn't make any difference. You can certainly probe > > the PCI bus for your device first, and if it isn't found, you just > > return -ENODEV or whatever. It's entirely up to you. > > > > What is important is to make sure that you free any resources > > that you acquired (like address space) if you decide not to > > install the module. This makes it so you can write the module, > > debug it, and add functionality without ever having to re-boot. > > > > Cheers, > > Dick Johnson > > Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips). > > Note 96.31% of all statistics are fiction. > > Thanks for the reply and sorry for the mailer issue (sent it from one of those > pop->web interfaces, not my usual mail client). > > > If I understand how pci_module_init works it registers a function (the probe > function) to be called with all harware that matches the id_table. Thus the > probe function won't be called at all unless some device matching the the > parameters passed to it is found. In that case there is no opportunity to > unregister the driver since the driver never gets control again. So I guess > I could restate my question as: > > 1) Is it correct that the driver won't get control again if no matching > devices are found? > > 2) If that's correct is it "legal" to call devfs_register_chrdev from a > function other than init (specifically from the probe function)? >
I would call pci_find_class() and continue until a NULL is returned or my vendor and device are returned in the structure. This is before I do anything else. That way, you know you have found your device. This is for up to at least version 2.4.24. There have been changes made in 2.6.eh, but I doubt that they got rid of the essential functions necessary to locate your device(s).
Cheers, Dick Johnson Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |