Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760902AbcDFHvi (ORCPT ); Wed, 6 Apr 2016 03:51:38 -0400 Received: from mx0a-0016f401.pphosted.com ([67.231.148.174]:33291 "EHLO mx0a-0016f401.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758285AbcDFHvh (ORCPT ); Wed, 6 Apr 2016 03:51:37 -0400 Date: Wed, 6 Apr 2016 15:47:40 +0800 From: Jisheng Zhang To: Ulf Hansson , Linus Torvalds , Peter Hurley , Jaehoon Chung CC: linux-mmc , Adrian Hunter , "linux-kernel@vger.kernel.org" Subject: Re: [bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6) Message-ID: <20160406154740.51715633@xhacker> In-Reply-To: References: <57008645.4070808@hurleysoftware.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-04-06_04:,, signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604060114 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2016 Lines: 51 Hi Ulf, On Tue, 5 Apr 2016 10:59:28 +0200 Ulf Hansson wrote: > On 4 April 2016 at 20:59, Linus Torvalds wrote: > > On Mon, Apr 4, 2016 at 4:29 AM, Ulf Hansson wrote: > >> > >> The commit that's likely to cause the regression is: > >> 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards > >> simultaneously"). > > > > Peter, mind testing if you can revert that and get the old behavior > > back? It seems to still revert cleanly, although I didn't check if the > > revert actually then builds.. > > I have checked, the revert should be a safe option. There is nothing > added on top that relies on it. > > Moreover, I have no problem dealing with the revert, as it me > personally that screwed this up. > > > > >> This commit further enables asynchronous detection of (e)MMC/SD/SDIO > >> cards, by converting from an *ordered* work-queue to a *non-ordered* > >> work-queue for card detection. > >> > >> Although, one should know that there have *never* been any guarantees > >> to get a fixed mmcblk id for a card. I expect that's what has been > >> assumed here. > > > > So quite frankly, for the whole "no regressions" issue, "documented > > behavior" simply isn't an issue. It doesn't matter one whit or not if > > something has been documented: if it has worked and people have > > depended on it, it's what we in the industry call "reality". > > > > And reality trumps documentation. Every time. > > I totally agree. > > Although, what puzzles me around this particular issue, is how an SoC > configuration can rely on this fragile behaviour. > All you have to do to break the assumption of fixed mmcblk ids, is to > boot with an SD card inserted and then without. Perhaps these SoCs > just doesn't support this use case!? This use case is supported by carefully always letting emmc host be probed before the sd hosts. For example, this can be done by putting the emmc host DT node before the SD hosts' ;) Thanks, Jisheng