[lkml]   [2005]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PATCH] More PCI patches for 2.6.13

On Sat, 10 Sep 2005, Jeff Garzik wrote:
> > happen, but still.. Relying on the legacy-value of the IO port instead of
> > relying on whether you did a legacy request_region() is definitely at
> > least conceptually wrong).
> Its not that simple. grep for ____request_region in both libata and the
> PCI quirks code. libata grabs the SATA port on ICH boxes in combined
> mode... but has to do so before built-in IDE driver grabs them.

That's not what I'm talking about.

The _request_ side is fine, and yes, it needs to be done early.

It's the module unload time that is broken - it doesn't remember whether
it requested the legacy mode addresses, so instead it uses the address
_values_ to determine if it did so or not, and that's broken: it is
conceivable at least in theory that a PCI BAR would contain the legacy
mode address value, without the legacy mode bit being set. In that case we
have _not_ done the legacy-mode "request_region()", but we _will_ do the

Exactly because the code checks the wrong thing. That's also the thing
that makes for problems for iomap. What used to be the wrong thing to test
now becomes _impossible_ to test.

If the code had just saved the value of "legacy_mode" from the probing
phase, the release phase wouldn't have any ambiguous cases, and the iomap
code wouldn't have any issues either..

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.045 / U:1.048 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site