Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux