On Wednesday, May 23, 2007 4:04 pm Robert Hancock wrote: > Jesse Barnes wrote: > > On Tuesday, May 22, 2007 6:06 pm Robert Hancock wrote: > >> There was a big discussion about this back in 2002, in which Linus > >> wasn't overly enthused about disabling the decode during probing > >> due to risk of causing problems with some devices: > >> > >> http://lkml.org/lkml/2002/12/19/145 > >> > >> In this particular case (64-bit BAR) we might be able to avoid the > >> problem by changing the order in which we probe the two halves of > >> the address, i.e. change the top half to 0xffffffff before messing > >> with the bottom half and then change it back last. That way, we > >> end up mapping it way to the top of 64-bit address space, which > >> hopefully is less likely to conflict.. > > > > Fixed it (finally). I don't think moving the 64 bit probing around > > would make a difference, since we'd restore its original value > > anyway before moving on to the 32 bit probe which is where I think > > the problem is. > > You couldn't just reorder the code the way it is now, you'd have to > rearrange the way we do things for 64-bit BARs: > > -write FFFFFFFF to high part of 64-bit address (we end up moving the > BAR to 0xFFFFFFFFC0000000 for example) > -If any bits stick, we know what the size is now (more than 4GB of > decode), so just change it back, we're done > -If not, we need to check the low part, so write FFFFFFFF to low part > of 64-bit address (BAR moves to 0xFFFFFFFFFFFFFFFF) > -Check which bits stick and calculate the address > -Change the low part of the address back (BAR moves to > 0xFFFFFFFFC000000) -Change the high part of the address back (BAR > moves to the original 0xC0000000 address) > > This means that at no point do we map the BAR anywhere near the top > of 32-bit memory, so we should avoid this issue in this particular > case. I don't think this strategy is too likely to break anything, > surely less likely than disabling command bits. Jesse, you might want > to try hacking up something like this and see what happens.
Ah yeah, that would probably work in this particular case, but doesn't seem very general. I think just using type 1 accesses for non-extended config space is a bit more solid. Jesse - 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/
