linux-kernel - RE: [PATCH v6 0/3]mmc: implement eMMC4.4 standard HW reset feature

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:	Tue, 11 Jan 2011 14:24:30 +0800
From:	"Dong, Chuanxiao" <chuanxiao.dong@...el.com>
To:	Chris Ball <cjb@...top.org>
CC:	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: RE: [PATCH v6 0/3]mmc: implement eMMC4.4 standard HW reset feature

Hi Chris, Thanks for your review! Below is my answer about your concerns.

> -----Original Message-----
> From: Chris Ball [mailto:cjb@...top.org]
> Sent: Tuesday, January 11, 2011 7:20 AM
> To: Dong, Chuanxiao
> Cc: linux-mmc@...r.kernel.org; linux-kernel@...r.kernel.org;
> akpm@...ux-foundation.org
> Subject: Re: [PATCH v6 0/3]mmc: implement eMMC4.4 standard HW reset feature
> 
> Hi Chuanxiao,
> 
> On Mon, Dec 27, 2010 at 06:13:05PM +0800, Chuanxiao Dong wrote:
> > Hi all,
> >    This is the version 6 of hardware reset feature implementation. When eMMC
> >    card cannot response any command, signal RST_n can help to reset eMMC
> >    card.
> >
> >    patch1: enable HW reset capability if card supports.
> >    patch2: do hardware reset if card occurs read/write/erase timeout
> >    patch3: implement hwreset_emmc and reinit_emmc callbacks. In this patch,
> >    hwreset_emmc callback will pull up/down the corresponded GPIO line
> number
> >    to trigger RST_n signal.
> 
> Sorry for the very late reply.  I'm simply not sure what to do about
> this patchset -- I'm extremely reluctant to touch the once-only
> programmable bits on the eMMC, and especially to do so silently by
> default.
Some eMMC4.4 or later new features need to touch the once-only programmable bits...If we support such features, we cannot avoid doing this. So do you think it is better for driver only read such once-only programmable bits? Writing such bits can leave to the manufactory line?
Or using a Kconfig option to notice user is better?

> 
> Also, where exactly do you assign host->rst_gpio?  It isn't assigned
> to in this patch, so where will it be set?  It looks like you could
Yes. host->rst_gpio was planned to put in host controller driver. But there is a dependence for getting the reset gpio number since different platform may use different gpios. I will send it out with my host controller support in the next submission for your review.

> end up strobing GPIO0 if a gpio isn't passed in at all.
Yes. If the rst_gpio was initialized by -ENODEV during host probing by default, this problem will be gone.

> 
> I haven't seen any other reports of -ETIMEDOUT from eMMC controllers
> not responding to CMD0; I wonder if only your controller has this
> problem, and if that should change how we handle it.
My host controller can also responding to CMD0. I am not sure if there will happen such scenario: eMMC card is in some error state and cannot respond any command in case during read/write/erase, host controller can still have another way to reset card and make it back to a normal working state. If such scenario occurs, HW reset feature can be used.

> 
> Does anyone else on the list have feedback on how best to proceed?
> 
> Thanks,
> 
> --
> Chris Ball   <cjb@...top.org>   <http://printf.net/>
> One Laptop Per Child
--
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/