> No, that totally avoids my point. Your "otherwise idle machine" test is > probably nowhere near worst case in the field, for loops that can > potentially lock the CPU for a long time upon hardware fault. And then > there are the huge delays in specific functions that I pointed out... > > Jeff
The problem is that these are the delays used in the original driver that we've been writing the specs from. We don't know what they're for or why they're so long. We don't know if reducing the delay will cause issues on some hardware and work fine on others. Without the actual specs from Broadcom, it's hard to say what's excessive and what's not and whether changing it will break the driver. -Joe - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
