On Sat, 27 May 2006, Jeff Garzik wrote: > > It is. But I thought you wanted something that works? :) I want something that can be _understood_ to work, and that clearly doesn't have any downsides. Waiting for the target to not be BUSY at resume is such an obviously understandable thing that it's not even funny. In contrast, having an unconditional half-second delay for each SATA port is not obvious at all, and has potentially huge downsides for totally unrelated users. > Your patch + Jens' patch [with the delay MOVED to the end] would get my ACK > for 2.6.17, and we already have infrastructure queued for 2.6.18 to do a > better job of kicking the controller and bus. No way am I adding a random half-second wait. One _millisecond_ or something similar clearly won't impact anybody else. But half a second for a condition that people don't even understand? > > discovery, while the other might instead try to see if the state _matches_ > > what it already knows. But the point is that coming back from power-off > > after a resume should really not be any different than coming back from > > power-off after a bootup) > > Key difference: we have no BIOS to give us sane hardware state, so the > controller is in a different state from bootup. Note that that is true sometimes on other platforms too, even at bootup. Maybe we've not had that issue with SATA, but we've definitely had it with just about any other hw config. Linus - : send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
