[U-Boot] [linux-sunxi] Re: [PATCH v2 10/10] ARM: sun6i: Add Colombus board defconfig

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 09/28/2014 11:36 PM, Ian Campbell wrote:
> On Sun, 2014-09-28 at 20:10 +0200, Hans de Goede wrote:
>> On 09/28/2014 06:20 PM, Ian Campbell wrote:
>>> On Sun, 2014-09-28 at 17:40 +0200, Hans de Goede wrote:
> 
>>>> Before you do that, note that I've just added 2 patches there, which I would
>>>> like to get into v2014.10. Specifically I'm hoping that I can get some
>>>> positive testing feedback on the bananapi gmac patch I've send (off-list),
>>>> and I believe we really should try to get the bananapi fix into v2014.10,
>>>> and if we're going todo a pull-req for v2014.10, we might as well include
>>>> the 2 patches I've just added to next. Do you agree ?
>>>
>>> You mean these two?
>>>         sun7i: Add support for Olimex A20-OLinuXino-LIME2
>>>         mmc: sunxi: add SDHC support for sun6i/sun7i/sun8i
>>
>> Yes.
>>
>>> The latter seems like a feature to me, or at least the changelog doesn't
>>> give any rationale why it should go in now rather than waiting for the
>>> next merge window (i.e. why it's a bugfix, what the upside is to justify
>>> its inclusion now). How much testing has it had and what are the
>>> potential downsides?
>>
>> AFAIK the downside is that High Capacity cards will not work without it.
>>
>> Looking at the code if this bit is set, then for some commands
>> drivers/mmc/mmc.c or-s in OCR_HCS into the mmc cmdarg, so I guess you're
>> right that this may cause some undesirable side effects, so lets delay
>> this one.
> 
> OK.
> 
>>> WRT the new board (and new boards generally), I'm in two minds. On the
>>> one hand they are pretty low risk (can't regress anything else, at least
>>> not in this case), on the other we are 6 weeks past the close of the
>>> merge window and 2 from the release date, so we are pretty far along.
>>> Where do we draw the line?
>>
>> Normally I would not include new boards at this moment in the cycle, but
>> since we need to do a pull-req for the gmac anyways I thought it would
>> be nice to have it included, esp. since many distros only spin things
>> like sdcard boot images once, so if we do not include it now, many distros
>> will not get it for a significant amount of time.
> 
> There's always Just One More Board(tm) ;-)

Right, so lets just drop the board and I'll do a pull-req with only the
bananapi gmac fix, can I have your Reviewed-by for that one please?

>> Either way let me know how you want to proceed, if you think we should not
>> include this, then I'll send a pull-req with only the gmac fix.
> 
> As I say I'm in two minds. I'm not really sure what the u-boot norm is
> on this, I was hoping someone might chime in (although it's not been
> very long and the thread topic doesn't exactly scream for attention).
> Maybe run it by Albert/Tom and see how they feel about such things in
> general?
> 
> Where run it by might be two alternate PRs? Or a PR structured so the
> new board can trivially be dropped?
> 
>>> The gmac fix is a clear bug fix and once it is properly posted publicly
>>> I will ack and then I agree it should go in.
>>
>> I was hoping for Stephen to get around to testing it today, and then I wanted
>> to send it out with his Tested-by. I'll just go and send it as is for now.
> 
> s/Stephen/Karsten/?

Yes, my bad.

Regards,

Hans