On Mon, Dec 6, 2010 at 10:28 AM, Simon Horman <simon@xxxxxxxxx> 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 <horms@xxxxxxxxxxxx> wrote: >> > Allow MMCIF_PROGRESS_* to be shared. >> > >> > Cc: Magnus Damm <magnus.damm@xxxxxxxxx> >> > Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx> >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html