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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 9 Oct 2015 10:29:57 +0200
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	Adrian Hunter <adrian.hunter@...el.com>
Cc:	Chaotian Jing <chaotian.jing@...iatek.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	Jaehoon Chung <jh80.chung@...sung.com>,
	Fabio Estevam <fabio.estevam@...escale.com>,
	Johan Rudholm <johan.rudholm@...s.com>,
	Gwendal Grignou <gwendal@...omium.org>,
	linux-mmc <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>,
	Sascha Hauer <kernel@...gutronix.de>
Subject: Re: [PATCH v2] mmc: core: Fix init_card in 52Mhz

[...]

>>> Then you need to remove the hw_reset test from mmc_test.  Refer:
>>>
>>>         http://marc.info/?l=linux-mmc&m=144360165906544&w=2
>>>
>>
>> I realize that the test becomes a bit different, but I don't think it's useless.
>>
>> If we add a check for MMC_CAP_HW_RESET and verify that the
>> host->ops->hw_reset exists, then we can assume that the "hw_reset"
>> sequence has executed. And if mmc_init_card() fails, that would
>> probably mean that the reset also failed, right?
>
> In the test case, the card is in a working state.  Generally I would then
> expect reinitialization to work irrespective of whether or not the hardware
> is actually reset.

That's not always the case. I have seen many strange things happening
while trying to re-initialize/reset the card. :-)

>
> Here are some other options:
>         1. have mmc_test hook the host->ops->hw_reset() fn and do the send_status
> itself.
>         2. have mmc_test set a flag on the card that it is being tested
> and only do the send_status if the flag is set

I assume that both 1) and 2) still means we need to manage the
scenario with re-tuning, which I rather would like us to prevent.

Unless we find a way to call mmc_set_initial_state() before doing the
reset, as that would disable re-tuning...

>         3. remove the send_status call and rename the mmc_test from "eMMC hardware
> reset" to just "Reset test (doesn't check hw reset did reset)"

That's would work and perhaps this is the best way to go as we would
then also be able to use the test for SD-cards. Let's do this then!

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ