From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757013AbcHWC6l (ORCPT ); Mon, 22 Aug 2016 22:58:41 -0400 Received: from mailout3.samsung.com ([203.254.224.33]:54352 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753312AbcHWC6j (ORCPT ); Mon, 22 Aug 2016 22:58:39 -0400 X-AuditID: cbfee68d-f79286d000007a9a-12-57bbbb8858d7 Subject: Re: [PATCH v2] mmc: dw_mmc: return -EILSEQ for EBE and SBE error To: Shawn Lin References: <1471834636-21057-1-git-send-email-shawn.lin@rock-chips.com> Cc: Ulf Hansson , linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, Doug Anderson , Brian Norris , Heiko Stuebner , linux-rockchip@lists.infradead.org From: Jaehoon Chung Message-id: Date: Tue, 23 Aug 2016 11:57:11 +0900 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-version: 1.0 In-reply-to: <1471834636-21057-1-git-send-email-shawn.lin@rock-chips.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsWyRsSkULdj9+5wg48NbBabPr5ntTi77CCb xf9Hr1ktLu+aw2Zx5H8/o8WnB/+ZLe48Wc9qcXxtuAOHx+yGiywed67tYfPYvKTe4++s/Swe 26/NY/b4vEkugC2KyyYlNSezLLVI3y6BK+Phs2WsBU8lKs7MP8TYwHhNuIuRk0NCwERi8u0Z TBC2mMSFe+vZuhi5OIQEVjBKTDt/lB2maP20LywgtpDAUkaJqa3cEPYDRonp2+VBbGEBT4m+ afsYQWwRAQ2JG2evQw2axygxY/cCRhCHWeAvo8TRjw/AprIJ6Ehs/3YcbDWvgJ3EkudzwWwW AVWJhh+tYNtEBcIkTp47xw5RIyjxY/I9sDgn0LaJ094CxTmAhupJ3L+oBRJmFpCX2LzmLTPI LgmBe+wS8/9MZ4GYKSDxbfIhFpB6CQFZiU0HmCEek5Q4uOIGywRGsVlINsxCmDoLydQFjMyr GEVTC5ILipPSiwz1ihNzi0vz0vWS83M3MQKj8PS/Z707GG8fsD7EKMDBqMTDu4N9d7gQa2JZ cWXuIUZToCMmMkuJJucDYz2vJN7Q2MzIwtTE1NjI3NJMSZxXUepnsJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbGqh2uFvxNVRNadFkMOy7s2Cze6JXtbr/Hymx6wO29Zcc7Qk8fffPORdvq TpAYn5nCY4vUK2W1wr4JukE3TJ7a8uQyzJ28NTB78q7Vt+bwJgd162Q3adbdcBJKflTBsiFj Zmx4w7ulX7WWXD26M/C6Nu/tl4+n9qcZ65pOKnlQoX1cWPhNS7kSS3FGoqEWc1FxIgCrRFBI vQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsVy+t9jAd2O3bvDDeYyW2z6+J7V4uyyg2wW /x+9ZrW4vGsOm8WR//2MFp8e/Ge2uPNkPavF8bXhDhwesxsusnjcubaHzWPzknqPv7P2s3hs vzaP2ePzJrkAtqgGRpuM1MSU1CKF1Lzk/JTMvHRbJe/geOd4UzMDQ11DSwtzJYW8xNxUWyUX nwBdt8wcoHOUFMoSc0qBQgGJxcVK+naYJoSGuOlawDRG6PqGBMH1GBmggYQ1jBkPny1jLXgq UXFm/iHGBsZrwl2MnBwSAiYS66d9YYGwxSQu3FvPBmILCSxllJjayg1hP2CUmL5dHsQWFvCU 6Ju2jxHEFhHQkLhx9jpQPRdQzTxGiRm7FzCCOMwCfxkljn58wA5SxSagI7H923EmEJtXwE5i yfO5YDaLgKpEw49WsM2iAmESJ8+dY4eoEZT4MfkeWJwTaNvEaW+B4hxAQ/Uk7l/UAgkzC8hL bF7zlnkCo8AsJB2zEKpmIalawMi8ilEitSC5oDgpPdcoL7Vcrzgxt7g0L10vOT93EyM4zp9J 72A8vMv9EKMAB6MSD++NvN3hQqyJZcWVuYcYJTiYlUR42YBJQog3JbGyKrUoP76oNCe1+BCj KdAbE5mlRJPzgSkoryTe0NjEzMjSyNzQwsjYXEmc9/H/dWFCAumJJanZqakFqUUwfUwcnFIN jAltBnWXciU9PolVukyI/ab25MhjkR2v5qxQWupz6kWYwKEERdWHJtoLnzk0XNnQ+/Xx13m/ i9Y+ZMj8l7jwgip/YsyP/Og/mktrQv+Iv4vZf2/t8pWvt8Wtask7Erxpg5265p+5nwUid2gt 2FYqukvjTbhz9TQFH7HTCTvPf+2ZoZoYK6Hc66DEUpyRaKjFXFScCABREOMuCQMAAA== DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Shawn, On 08/22/2016 11:57 AM, Shawn Lin wrote: > The following log we found indicate the fact that dw_mmc > didn't treat EBE or SBE as a similar problem as CRC error. > -EIO is quite not informative as it may indicate that the device > is broken rather than that of tuning stuff. > > ... > [ 89.057226] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5 > [ 89.058811] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5 > [ 89.059415] bcmsdh_sdmmc: Failed to Read byte F1:@0x1000e=ff, Err: -84 > [ 89.254248] dwmmc_rockchip fe310000.dwmmc: Successfully tuned phase to 199 > [ 89.273912] dhd_set_suspend: Remove extra suspend setting > [ 89.274478] dhd_enable_packet_filter: enter, value = 0 > 64 bytes from 112.90.83.112: icmp_seq=24 ttl=53 time=1321 ms > 64 bytes from 112.90.83.112: icmp_seq=25 ttl=53 time=319 ms > 64 bytes from 112.90.83.112: icmp_seq=26 ttl=53 time=69.8 ms > 64 bytes from 112.90.83.112: icmp_seq=27 ttl=53 time=37.5 ms > ... > > For the host, when failing to sample cmd's response due to > tuning stuff, we still return -EIO as it's quite vague to figure > out whether it related to signal or just the broken devices, especially > for the card type detection when booting kernel as all things go well > but the cmd set used. > > But for the data phase, if receiving the cmd's response which > carriess data transfer, we should have more confidence that it > is very probably related to the tuning stuff. > > Just as the log shown above, we sometimes suffer too much > this kind of pain as the dw_mmc return -EIO for the case, so > mmc-core will not do retune and caller drivers like bcm's wifi > driver, still retry the failure more and more until dw_mmc > finally generate CRC. > > Adrian suggested that drivers who care the specific cases should > call mmc_retune_needed rather than doing it in mmc core. It makes > sense but I'm considering that -EILSEQ actually means illegal sequence > , so we use it for CRC cases. Meanwhile, SBE/EBE indicate the illegal > sequence of start bit or end bit for data0~7. So I realize that we should > use -EILSEQ for them both as well CRC cases. Applied on my repository. Thanks! Best Regards, Jaehoon Chung > > Suggested-by: Adrian Hunter > Signed-off-by: Shawn Lin > > --- > > Changes in v2: > - fix some typos found by Jaehoon > > drivers/mmc/host/dw_mmc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c > index 32380d5..b36a4f5 100644 > --- a/drivers/mmc/host/dw_mmc.c > +++ b/drivers/mmc/host/dw_mmc.c > @@ -1691,11 +1691,11 @@ static int dw_mci_data_complete(struct dw_mci *host, struct mmc_data *data) > data->error = -ETIMEDOUT; > } else if (host->dir_status == > DW_MCI_RECV_STATUS) { > - data->error = -EIO; > + data->error = -EILSEQ; > } > } else { > /* SDMMC_INT_SBE is included */ > - data->error = -EIO; > + data->error = -EILSEQ; > } > > dev_dbg(host->dev, "data error, status 0x%08x\n", status); >