Re: [patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux