> there strong counter-arguments against doing the clean thing and adding#1 udelay has to be for the worst case bus clock (6MHz) while the device may be at 10Mhz or even 12MHz ISA. So it slows it down stuff unneccessarily- and stuff that really really is slow enough as is. #2 Most of the ancient wind up relics with ISA bus don't have a tsc so their udelay value is kind of iffy. #3 Not changing it is the lowest risk for a lot of the old ISA code that never occurs on newer boxes If we have an isa_inb_p() as a specific statement of "I am doing an ISA bus dependant delay on ancient crap hardware" then we can avoid the risk of breakage. We wouldn't use it for non ISA, and certainly not for stuff like chipset logic which requires a more thorough fix as it occurs on all kinds of boxes. ISA bus cycles are *slow*, the subtle processor cache and gcc triggered timing changes are lost in the noise. Alan --
| Jeff Chua | 2.6.27rc1 cannot boot more than 8CPUs |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Winkler, Tomas | RE: iwlwifi: fix build bug in "iwlwifi: fix LED stall" |
| Evgeniy Polyakov | Re: [BUG] New Kernel Bugs |
git: | |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Andrew Dickinson | tx queue hashing hot-spots and poor performance (multiq, ixgbe) |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
