From mboxrd@z Thu Jan 1 00:00:00 1970 From: Magnus Damm Date: Mon, 06 Dec 2010 01:38:15 +0000 Subject: Re: [patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h Message-Id: List-Id: References: <20101206001243.949375995@vergenet.net> <20101206001310.658304531@vergenet.net> <20101206012801.GA3735@verge.net.au> In-Reply-To: <20101206012801.GA3735@verge.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On Mon, Dec 6, 2010 at 10:28 AM, Simon Horman wrote: > On Mon, Dec 06, 2010 at 09:57:17AM +0900, Magnus Damm wrote: >> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman wrote: >> > Allow MMCIF_PROGRESS_* to be shared. >> > >> > Cc: Magnus Damm >> > Signed-off-by: Simon Horman >> >> I'm a bit hesitant to this change. This because the progress really >> hasn't anything to do with the MMCIF hardware block. The enum does use >> the MMCIF prefix though, so I guess i should be silent. =) >> >> In the future I can imagine that there will be more boards making use >> of this feature, and other MMC/SD-capable hardware blocks that want to >> support early loading. Perhaps moving the enum into the header like >> you suggest is the easiest way forward. Unless there is any easy way >> to share the same progress code between MMCIF and say SDHI. > > The way that I see things is that with the last patch in this series > there are two files using these enums, one under arch/sh and one under > arch/arm. They both relate to using MMCIF. And they both assume that > there are states we are interested in that can be usefully displayed. Sure. > If SHDI can make use of this it may make sense to move it somewhere > else at that time. Yeah, dealing with it at that point is probably the easiest. > OTOH, its just 4 integers and this is really just debugging code. > I wouldn't be opposed to removing it altogether. I'd rather keep it. The MMC loader code is a rather new development so having some early debug output option makes sense. Thanks, / magnus