All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@gmail.com>
To: Rogier Wolff <R.E.Wolff@BitWizard.nl>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, support@specialix.co.uk
Subject: Re: [PATCH 4/9] Char: sx, remove unneeded stuff
Date: Tue, 31 Oct 2006 16:20:30 +0100	[thread overview]
Message-ID: <454769BE.6070300@gmail.com> (raw)
In-Reply-To: <20061031074907.GA2031@bitwizard.nl>

Rogier Wolff wrote:
> 
> Hi,
> 
> When you work on a driver, it has happened to me multiple times that
> I forget to acknowledge the interrupt to the hardware. This is when
> the "rate limit" converts a solid hang ("what the <beep> is going on?)
> into a console message that "your interrupt is triggering too much". 
> 
> This reduces development time on the driver, which I think is worth
> the 20 or so inactive lines-of-code that this requires in the source. 
> 
> Also proposed to be deleted the defines that I added to remind me
> of the possibility to report fifo overruns. Other drivers have this
> capability, but much smaller buffers. So it hasn't been neccesary
> yet. For now it remains unimplemented. But I would prefer to keep
> the notes of the possibility of this enhancement in the driver source
> instead of somewhere else. 

Aaah, OK.

> Apparently, someone deleted the call to the word-wide memory test. So 
> now the memory test seems dead code. I've had clients call for support 
> where after debugging a while, the conclusion was: you may have a corruption
> problem between the CPU and the card. Enable memory test, and voila!
> Proof that there is something seriously wrong with the hardware setup!

Maybe we could have this as a CONFIG_SX_MEMTEST option?

> This debugging feature is uncommon enough that I recommend leaving it
> compile-time-disabled. The other debugging features are compile time
> enabled, run-time-disabled. This allows end-users to send in detailed
> debugging reports without having to recompile the driver, which usually
> costs them a lot of time. 

I agree.

> The other "small" cleanups look ok. 

Ok, thanks for notes,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

      reply	other threads:[~2006-10-31 15:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-31  0:42 [PATCH 4/9] Char: sx, remove unneeded stuff Jiri Slaby
2006-10-31  7:49 ` Rogier Wolff
2006-10-31 15:20   ` Jiri Slaby [this message]

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=454769BE.6070300@gmail.com \
    --to=jirislaby@gmail.com \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=support@specialix.co.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.