From: Jeff Garzik <jgarzik@pobox.com>
To: Grant Grundler <grundler@parisc-linux.org>, akpm@osdl.org
Cc: T-Bone@parisc-linux.org, varenet@parisc-linux.org,
Linux Kernel <linux-kernel@vger.kernel.org>,
Netdev <netdev@oss.sgi.com>
Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree
Date: Fri, 20 May 2005 14:58:58 -0400 [thread overview]
Message-ID: <428E3372.403@pobox.com> (raw)
In-Reply-To: <20050516222612.GD9282@colo.lackof.org>
Grant Grundler wrote:
> After three years of using/maintaining the (trivial) tulip patch
> in parisc-linux tree (and shipped with RH/SuSe ia64 releases),
> I don't recall anyone complaining that udelays in tulip phy reset
> caused them problems. Sorry, I'm unmotivated to revisit this.
> Convince someone else to make tulip to use workqueues and I'll
> resubmit a clean patch on top of that for the phy init sequences.
Long delays are unacceptable in new drivers, and we are working to
remove them from older drivers. Lack of complaints is irrelevant -- its
a design requirement of all drivers.
Ingo and the real-time crowd are fighting against every delay, because
every delay causes a spin, a blip in latency, an increase in CPU usage,
and a complete stoppage of ALL work on a uniprocessor machine.
Your patch is not a special case. We have been communicating this
message on udelay/mdelay for -years-. All your patch [as-is] does is
cause more work for someone else.
This also presents a problem that Andrew points out on occasion:
what happens when a patch is useful, but the patch author isn't (for
whatever reason) doing the legwork necessary to get it into the mainline
kernel? We certainly DON'T want to lose this patch, as the changes are
useful.
Jeff
next prev parent reply other threads:[~2005-05-20 18:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net>
2005-05-16 4:06 ` patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree Jeff Garzik
2005-05-16 5:08 ` Grant Grundler
2005-05-16 16:46 ` Jeff Garzik
2005-05-16 22:26 ` Grant Grundler
2005-05-20 18:58 ` Jeff Garzik [this message]
2005-05-20 19:15 ` Francois Romieu
2005-05-20 21:12 ` Grant Grundler
2005-05-20 21:34 ` Jeff Garzik
2005-05-21 0:51 ` Grant Grundler
2005-05-21 22:39 ` Francois Romieu
2005-05-22 4:56 ` Grant Grundler
2005-05-27 2:16 ` Jeff Garzik
2005-05-27 7:17 ` Francois Romieu
2005-10-04 13:18 ` Jeff Garzik
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=428E3372.403@pobox.com \
--to=jgarzik@pobox.com \
--cc=T-Bone@parisc-linux.org \
--cc=akpm@osdl.org \
--cc=grundler@parisc-linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=varenet@parisc-linux.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;
as well as URLs for NNTP newsgroup(s).