Hello, Jian.
On 12/08/2010 09:09 PM, Jian Peng wrote:
I don't necessarily agree there. The requirement is impossible to
reliably satisfy to begin with (it's inherently racy) and most specs
are filled with "the outcome is undefined" when they don't _need_ to
be well defined. The hardware can do "eh.. well, whatever, I don't
know" but shouldn't get lost and fail to react to further
state-resetting actions.
Okay, so, the controller goes bonkers if ST is set when prerequisites
are not met. You know that the problem can still happen with the
proposed change, right? It's much less likely but definitely can and
actually is likely to happen once in a blue moon. It isn't too
uncommon for link to take some time to stabilize after a PHY event
(including hardreset) and some devices will end up sending multiple
D2H Reg FISes in the process with conflicting status. Also, note that
the delay between the check and ST setting could be substantial
especially with parallel probing / booting.
I'm not objecting to the change but you guys probably want to fix the
controller in following revisions. If we're gonna make the change,
I'd like to go with the previous version without the vendor check.
What is the timeframe for the controller release? Would it be enough
to merge the change during 2.6.38-rc1? After baking it for some time
in 2.6.38, we can propagate the change back through -stable.
Thanks.
--
tejun
--
