Messages in this thread | | | Date | Fri, 19 Oct 2007 00:08:24 +0200 | From | Jiri Slaby <> | Subject | Re: RocketPort Linux driver errors on module reload |
| |
On 10/18/2007 11:53 PM, Ferenc Wagner wrote: > "Jiri Slaby" <jirislaby@gmail.com> writes: > >> On 10/16/07, Wagner Ferenc <wferi@niif.hu> wrote: >> >>> Jiri Slaby <jirislaby@gmail.com> writes: >>> >>>> Are you willing to test to-pci-probing patches (i.e. patches which >>>> converts the driver to the model introduced in linux 2.4)? >>> Well yes. We've got a copule of such cards, which raises some >>> interest in a proper driver. Just send the patches with some >>> instructions along, or point me to a git branch if you prefer. >> Maybe the git with stand-alone module would be better... > > Sorry, I don't understand this suggestion. I don't read LKML, please > don't suppose any prior knowledge of the jargon used here... Do you > mean I should use the bleeding edge git source of the kernel? Not > something I'm eager to do, but can do, actually. And would you send > me patches separately on top of that?
I meant the creating of a git repository with only the module would be the easiest possible and most comfortable way for you :). Otherwise I can post you a patch serie.
>>>> If not, I'll only increment the counter on modprobe and decrement it >>>> on rmmod, since it would be a safe (in the meaning of not changing >>>> that much code) way of fixing the problem. >>> And what are the drawbacks of this simple solution? >> Nothing, but it's not the proper way -- just a safe fallback. But you >> can still say no :). > > I expected an improper way to have some disadvantages at least. :)
Yes, if you have pci hotpluggable motherboard :). Pci probing (the new method) allows you adding/probing pci devices on the fly, not only when the module is loading.
> Anyway, I can tolerate some glitches during the porting of this > module, resulting in interruptions of the serial devices, but leaving > the rest of the system mostly stable; it's a production system after > all. If the changes are more threatening, I'll use another system for > the tests. In short: suggest a method and let's give a chance for the > proper solution. Just please enclose some risk assessment.
I did such switches in drivers several times yet, but I can't assure you, that I won't make any mistake, but this driver seems not to need too many changes. Maybe functionality regressions would occur rather than instability of system.
Anyway I would rather wait for the changes from comtrol to not break their upcoming patches (if they post them in some short term) and then do these changes.
thanks, -- Jiri Slaby (jirislaby@gmail.com) Faculty of Informatics, Masaryk University - 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/
| |