On 10 Jan 00 at 21:08, Martin Mares wrote:
> > I just updated my matroxfb to new pci_{un}register_driver interface
> I'm not sure how wise is updating drivers to the new interface now --
> it's quite a moving target. Better wait several days before it stabilizes.
It saved some code for me, as I do not have to remember matroxfb instances
anymore - pci remembers them for me... And after I persuade friend with IBM
and hotplug PCI to compile matroxfb into kernel, I can try to hotswap
matroxes... (but it is probably 2.5 task, as current diff between
my G400DH aware matroxfb and kernel is 482kB :-( )
> > and I'd like to ask few questions:
> > (1) probe callback should return 0 on failure and !=0 on success.
> > Is success value somewhat standardized for future compatibility?
> > Why it is not 0=success, !=0 error with returning errno.h compatible
> > values (-ENOMEM, -ENXIO, ...)?
> You're right, it would be better to use <0 for errors. I'll change that.
If you want hide pci_dev->driver_data item from users, you can change probe
to void* (*probe)(struct pci_dev*) and define that NULL means failure and
non-NULL means success and should be stored in driver_data for
remove/resume/suspend callbacks.
> > (3a) Can probe & remove callback sleep or should I spawn init/cleanup
> > thread when I need sleep (non-atomic kmalloc and so on? (but doing
> > cleanup with thread is impossible in remove callback)
> Currently it cannot sleep as it's called from timer, but I hope this
> will change soon.
It looks like that I had enough free memory and enough luck when I tried
that...
> > (3b) Should not you protect pci_for_each_dev() and pci_remove_device()
> > with some mutex (or add an usecount to pci_dev)? Are there some
> > other conditions (except that currently no-one calls
> Currently they should be protected by the global kernel lock.
It looks reasonable for registration/unregistration, but you should
document it somewhere for pci_find* and pci_for_each_dev().
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:16 EST