Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932134Ab0LHWyz (ORCPT ); Wed, 8 Dec 2010 17:54:55 -0500 Received: from hera.kernel.org ([140.211.167.34]:41343 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756230Ab0LHWyy (ORCPT ); Wed, 8 Dec 2010 17:54:54 -0500 Message-ID: <4D000C8B.5040904@kernel.org> Date: Wed, 08 Dec 2010 23:54:03 +0100 From: Tejun Heo User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jian Peng CC: Robert Hancock , "linux-kernel@vger.kernel.org" , "jgarzik@pobox.com" , ide Subject: Re: questions regarding possible violation of AHCI spec in AHCI driver References: <4CFEE569.4030204@gmail.com> <4CFF58D2.4040006@kernel.org> ,<4CFFCD56.6050608@kernel.org> ,<4CFFD3EB.10800@kernel.org> <4CFFE29C.7080205@kernel.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (hera.kernel.org [127.0.0.1]); Wed, 08 Dec 2010 22:54:10 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2105 Lines: 46 Hello, Jian. On 12/08/2010 09:09 PM, Jian Peng wrote: > The controller may take much longer time to recover in this case, > and leads to wrong HW state after stop_engine() inside > ahci_hardreset() and cause device type checking failure due to > unfinished HW state change and missing D2H FIS after start_engine() > again inside ahci_hardreset(). I guess this is the reason why AHCI > spec try to emphasize. 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. > Yes, without this change, Broadcom controller will fail due to above > reason. 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 -- 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/