mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ferenc Wagner <wferi@niif.hu>
To: "Jiri Slaby" <jirislaby@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: RocketPort Linux driver errors on module reload
Date: Thu, 18 Oct 2007 23:53:50 +0200	[thread overview]
Message-ID: <87ve94ccnl.fsf@tac.ki.iif.hu> (raw)
In-Reply-To: <4af2d03a0710161419n3727dbfev10b1319599d30b49@mail.gmail.com> (Jiri Slaby's message of "Tue, 16 Oct 2007 23:19:28 +0200")

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

>>> 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. :)

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.
-- 
Regards,
Feri.

  reply	other threads:[~2007-10-18 21:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-15  9:55 Ferenc Wagner
2007-10-15 11:25 ` Jiri Slaby
2007-10-15 12:57   ` Ferenc Wagner
2007-10-15 19:09     ` Jiri Slaby
2007-10-16  7:47       ` Wagner Ferenc
2007-10-16 21:19         ` Jiri Slaby
2007-10-18 21:53           ` Ferenc Wagner [this message]
2007-10-18 22:08             ` Jiri Slaby
2007-10-18 22:48               ` Ferenc Wagner
2007-10-17 17:06 Nick Thompson
2007-10-17 19:35 ` Jiri Slaby
2007-10-17 19:48   ` Nick Thompson
2007-10-18 22:08     ` Jiri Slaby
2007-10-18 23:02       ` Nick Thompson
2007-12-08 10:00         ` Jiri Slaby

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ve94ccnl.fsf@tac.ki.iif.hu \
    --to=wferi@niif.hu \
    --cc=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome