proper place for devfs_register_chrdev with pci_module_init

proper place for devfs_register_chrdev with pci_module_init

[Oliver Dain]

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?

I'm not subscribed to the LKML so please CC me on any responses.

Thanks,
Oliver

Re: proper place for devfs_register_chrdev with pci_module_init

[Richard B. Johnson]

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.

Re: proper place for devfs_register_chrdev with pci_module_init

[odain2]

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)?

Thanks,
Oliver

PS: I'm not subscribed to LKML so please CC responses.

Re: proper place for devfs_register_chrdev with pci_module_init

[Richard B. Johnson]

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.

Re: proper place for devfs_register_chrdev with pci_module_init

[Greg KH]

On Wed, Feb 04, 2004 at 05:29:31PM -0500, Richard B. Johnson wrote:
> 
> I would call pci_find_class() and continue until a NULL is returned
> or my vendor and device are returned in the structure.

NOOOOO!!!!!

Do NOT do this.  Use pci_register_driver() instead.  Using pci_find_*()
is just broken and wrong for 99% of all pci drivers.

If you do this you do not hook up into sysfs properly.  You do not get
modules automatically loaded for your driver.  You do not get notified
if the device is removed from the system.  And, most importantly, you do
not get exclusive access to the pci device.

As for the original poster, look at one of the many existing char
drivers for examples of what you need to do to register a char driver
properly.  It really has nothing to do with the pci interface at all
(with the exception of when to register it...)

thanks,

greg k-h

Re: proper place for devfs_register_chrdev with pci_module_init

[Richard B. Johnson]

On Wed, 4 Feb 2004, Greg KH wrote:

> On Wed, Feb 04, 2004 at 05:29:31PM -0500, Richard B. Johnson wrote:
> >
> > I would call pci_find_class() and continue until a NULL is returned
> > or my vendor and device are returned in the structure.
>
> NOOOOO!!!!!
>
> Do NOT do this.  Use pci_register_driver() instead.  Using pci_find_*()
> is just broken and wrong for 99% of all pci drivers.
>
> If you do this you do not hook up into sysfs properly.  You do not get
> modules automatically loaded for your driver.  You do not get notified
> if the device is removed from the system.  And, most importantly, you do
> not get exclusive access to the pci device.
>
> As for the original poster, look at one of the many existing char
> drivers for examples of what you need to do to register a char driver
> properly.  It really has nothing to do with the pci interface at all
> (with the exception of when to register it...)
>
> thanks,
>
> greg k-h


WTF? How do you find out if your board in actually in the system?
You CANNOT load all possible modules, hoping that somebody will
hot-plug in one of the devices a year from now.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: proper place for devfs_register_chrdev with pci_module_init

[Greg KH]

On Thu, Feb 05, 2004 at 07:42:06AM -0500, Richard B. Johnson wrote:
> On Wed, 4 Feb 2004, Greg KH wrote:
> 
> > On Wed, Feb 04, 2004 at 05:29:31PM -0500, Richard B. Johnson wrote:
> > >
> > > I would call pci_find_class() and continue until a NULL is returned
> > > or my vendor and device are returned in the structure.
> >
> > NOOOOO!!!!!
> >
> > Do NOT do this.  Use pci_register_driver() instead.  Using pci_find_*()
> > is just broken and wrong for 99% of all pci drivers.
> 
> WTF? How do you find out if your board in actually in the system?
> You CANNOT load all possible modules, hoping that somebody will
> hot-plug in one of the devices a year from now.

It is interesting how all of the words in your reply seem to make real
sentances, yet those sentances have nothing to do at all with the topic
at hand.

Please stop trolling the newbies, as much fun as it may seem, it's not a
nice thing to do.

greg k-h