From: Arjan van de Ven <arjanv@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
"David S. Miller" <davem@redhat.com>,
geert@linux-m68k.org, Christoph Hellwig <hch@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dledford@redhat.com, Jens Axboe <axboe@suse.de>
Subject: Re: [PATCH] NCR53C9x ESP: C99 designated initializers
Date: 11 Nov 2002 18:43:15 +0100 [thread overview]
Message-ID: <1037036596.2441.3.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44.0211110915470.1805-100000@home.transmeta.com>
[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]
On Mon, 2002-11-11 at 18:24, Linus Torvalds wrote:
>
> On 11 Nov 2002, Alan Cox wrote:
> >
> > The stupid thing is we take the lock then call the eh function then drop
> > it. You can drop the lock, wait and retake it. I need to fix a couple of
> > other drivers to do a proper wait and in much the same way.
>
> Hmm.. I wonder if the thing should disable the queue (plug it) and release
> the lock before calling reset. I assume we don't want any new requests at
> this point anyway, and having the low-level drivers know about stopping
> the queue etc sounds like a bad idea..
something similar is needed in the scsi layer for other reasons too; I
can imagine something that behaves similar as the network layer's
netif_stop_queue() and allows drivers to inform the upper layer to stop
trying to submit requests to the lower level driver. Fiber channel
drivers can do this for example on LIP down (and enable again on LIP
up). LIP is not the only reason this is useful; overall I estimate that
over half of the code in the (out of tree) qlogic 2x00 driver can be
removed if this functionality was available.
Greetings,
Arjan van de Ven
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2002-11-11 18:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-03 10:46 [PATCH] NCR53C9x ESP: C99 designated initializers Geert Uytterhoeven
2002-11-03 13:13 ` Christoph Hellwig
2002-11-03 14:28 ` Geert Uytterhoeven
2002-11-03 14:33 ` Christoph Hellwig
2002-11-10 10:27 ` Geert Uytterhoeven
2002-11-10 14:38 ` Alan Cox
2002-11-11 9:31 ` Geert Uytterhoeven
2002-11-11 9:43 ` David S. Miller
2002-11-11 13:05 ` Alan Cox
2002-11-11 17:24 ` Linus Torvalds
2002-11-11 17:43 ` Arjan van de Ven [this message]
2002-11-11 20:31 ` Doug Ledford
2002-11-11 22:48 ` Alan Cox
2002-11-11 20:35 ` Doug Ledford
2002-11-11 21:01 ` Linus Torvalds
2002-11-11 21:24 ` Doug Ledford
-- strict thread matches above, loose matches on Subject: below --
2002-11-11 18:30 J.E.J. Bottomley
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=1037036596.2441.3.camel@localhost.localdomain \
--to=arjanv@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=axboe@suse.de \
--cc=davem@redhat.com \
--cc=dledford@redhat.com \
--cc=geert@linux-m68k.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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