On Sun, 2007-12-09 at 13:38 +0000, Alan Cox wrote: > > has, I don't know for sure), we have a quirk that puts those > controller > > back into native mode. But so far, those quirks didn't change the > > resources as they were supposed to contain the proper BAR values > that > > would, from then, be used. > > Then your quirk is faulty (for the general case). The BAR values are > undefined at that point, they may not even be writable.
Possibly, however, the fact is that those quirks "just worked" on all HW where we used them in the past, so while in "theory" they are incorrect, in practice, this is a regression and thus needs to be fixed. > Improbable unless its willing to rely on entirely undefined behaviour. I would argue to you that the whole legacy PCI thing is mostly "undefined behaviour" from day 1. We rely on what worked in practice for us, period. It's broken now, this is a regression. I'm not saying we should revert the change in the generic code, I'm just raising an alarm here as I doubt we are the only platform to do that (heh, I didn't even write those quirks in the first place) and some fixing is needed in that area. I'm totally fine with changing the quirks to do the "right" though. > If you kick the device out of legacy mode (itself very very board > dependant) then you must find a suitable new resource allocation for > the controller. Quite possibly, though as I said in practice, what we did so far happened to "just work" on pretty much everything we were faced with (which iirc is basically winbond and VIA controllers, possibly a few others). Anyway, I'll scrub around. Again, I'm not saying the approach is wrong in the generic code. Ben. -- 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/
