lkml.org 
[lkml]   [2005]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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
"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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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