Re: [GIT PATCH] More PCI patches for 2.6.13

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

 




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 
"release_region()".

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..

		Linus
-
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]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux