Rene Herman wrote:
On 17-12-07 17:12, Alan Cox wrote:
I don't think we should be offering udelay based delays at this point.
There are a lot of drivers to fix first. This is just one trivial example
I agree. This thread's too full of people calling this outb method a
dumb hack. It's a well-known legacy PC thing and while in practice the
udelay might be a functional replacement for a majority of cases (save
the races you are finding) a delay proportional to the bus speed makes
great sense certainly when talking to hardware that itself runs
proportinal to the bus speed for example.
So, really, how about just sticking in this minimal version for now?
Only switches the port to 0xed based on DMI and is all that is needed to
fix the actual problem. This should be minimal and no-risk enough that
it could also go to .24 if people want it to. It'll fix a few HP laptops
(I'll try and get/verify the dv6000z DMI strings as well).
I think retaining the command-line option available is a good thing,
though. If nothing else, it is something very quick we can ask other
people to try if they seem to have similar problems.
Other than that, this alternate-port patch is a low-impact patch not
affecting hardware not on the blacklist, which makes it appropriate for
2.6.24 IMO.
-hpa
--
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/