Re: proper place for devfs_register_chrdev with pci_module_init

[Richard B. Johnson]

On Wed, 4 Feb 2004 odain2@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/