lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 29 Mar 2017 10:27:55 +0800 From: Chaotian Jing <chaotian.jing@...iatek.com> To: Ulf Hansson <ulf.hansson@...aro.org> CC: Adrian Hunter <adrian.hunter@...el.com>, Matthias Brugger <matthias.bgg@...il.com>, Jaehoon Chung <jh80.chung@...sung.com>, Shawn Lin <shawn.lin@...k-chips.com>, Masahiro Yamada <yamada.masahiro@...ionext.com>, "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, <linux-mediatek@...ts.infradead.org>, srv_heupstream <srv_heupstream@...iatek.com> Subject: Re: [PATCH] mmc: core: Do not hold re-tuning during CMD6 commands On Tue, 2017-03-28 at 11:59 +0200, Ulf Hansson wrote: > [...] > > >> The retry mechanism provided by mmc_wait_for_cmd() and friends really only > >> makes sense for simple commands. In other cases, like this, we need to > >> consider what state the card is in. For __mmc_switch we need to consider > >> whether the card is busy or whether a timing change been made. > > > > I definitely agree. We should remove retries for CMD6 and perhaps also > > for some other cases. > > just only remove retries ? how to do error handle of CMD6 response CRC error ? > > When we have changed the above in __mmc_switch(), the change Chaotian > > suggest gets a different impact, as it would potentially allow a > > re-tuning to happen before the next CMD1to poll for busy or to check > > /s/CMD1/CMD13 > > > the switch status. This isn't okay. > > > > This all sounds to me that Chaotian's issue may not all be related to > > tuning, but to the CMD6 switch sequence itself. However I may be wrong > > - of course. :-) We had already noticed this issue and do busy check before CMD6 was sent in our host driver. so that for me, the rest work is to do re-tune before the next cmd6... > > > > [...] > > > > Kind regards > > Uffe
Powered by blists - more mailing lists