[U-Boot] [SoCFPGA] next steps

[Jagan Teki]

On 9 October 2014 14:07, Michal Simek <monstr at monstr.eu> wrote:
> Hi,
>
> On 10/08/2014 10:09 PM, Tom Rini wrote:
>> On Wed, Oct 08, 2014 at 10:58:24AM +0200, Michal Simek wrote:
>>> Hi,
>>>
>>> On 10/07/2014 02:45 PM, Marek Vasut wrote:
>>>> Hey,
>>>>
>>>> given that we now have most of the u-boot socfpga stuff in mainline, I decided
>>>> it would be a good idea to list what we're still missing and we should also
>>>> decide how to move on now.
>>>>
>>>> First thing I should probably clarify is the late acceptance of the socfpga
>>>> patches. This is certainly not something we do regularly and is one of the
>>>> worst possible practices to do, but this time it felt rather important to get
>>>> the platform in shape, so this exception happened. Furthermore, all of the code
>>>> in u-boot-socfpga should be based on u-boot-arm and should be submitted through
>>>> the u-boot-arm repository, not directly to u-boot .
>>>
>>> Platform was in this shape for a while that's why I can't see the
>>> reason why this happen.
>>>
>>> Tom: Does it mean that every platform which is not in good shape can
>>> go directly to the mainline in any time? It is definitely something
>>> which is good to know.
>>
>> So, it's a long standing thing where for non-core changes, deferring to
>> the relevant custodian about what's going to come in close to the
>> release is what's done.  So yes, I grilled Marek about what non-socfpga
>> things would be impacted by the changes (RPi) and if he'd tested things
>> there.  It all had been through a few post/review cycles.
>>
>> There's an argument to be made that we shouldn't have let socfpga in,
>> back in 2012 or should have pushed harder, sooner, to get more progress
>> made on "real" platform support.
>
> AFAIK if platform is working in certain state and you are able to get
> for example console than there is no problem to be in. There is nowhere
> written what exactly should work that's why I can't see any problem
> that socfpga is in if it is not causing compilation issues and have at
> least minimum functionality.
>
> The question was if the problem was that Altera just failed because
> didn't collect patches to any repo and sending it to Albert.
> Or there was just misunderstanding that Albert expected that Altera
> will do that and Altera expected that Albert will pick it up
> because he is ARM custodian and none was listed for socfpga.
> I have to defend Altera guys because if none is listed for SocFpga
> the nearest maintainer is collecting patches.
>
> Then there was discussion that none did care about socfpga patches
> and problem was resolved by creating socfpga repository and Marek became
> custodian for it. Marek collected that patches to the new repo and
> also I believe add new one and rebased them on the top of current tree
> and send them out as one big 51 series which is not possible to even properly
> review.
> IMHO they should be sent separated to target exact audience which do care
> about spi/i2c/watchdog/fpga/soc etc. But maybe that's just matter of taste.
>
> But I am still missing the point why that patches was that urgent
> that they were merged to rc3 when it was claimed that socfpga was in a wrong
> shape for a while. It means v2014.10 should be just another broken version
> for socfpga and all this mess should be solved properly in 2015.01 via socfpga
> repo.
>
> And because patches went into rc3 and yesterday Jeroen is reporting problem
> on FreeBSD because of this merge.(http://patchwork.ozlabs.org/patch/397453/)
>
> Regarding your point that all "It all had been through a few post/review cycles."
> I don't think all things have been fixed.
> Personally me I have reported here
> http://lists.denx.de/pipermail/u-boot/2014-September/189741.html
> (sha1: 0ae16cbb40a2881f6dfbe00fcb023ee7b548bc5c)
> issue with checkpatch.pl which hasn't been fixed.
>
> Here is my ACK for one patch which is not present in mainline commit
> http://lists.denx.de/pipermail/u-boot/2014-September/189747.html
> (sha1: 2f210639c4f003b0d5310273979441f1bfc88eae)
>
> Make no sense to go through all patches but this is just an example.
>
>
> I think it is something what we should discuss at u-boot mini summit
> on Monday. I discussed this with Marek over IRC yesterday and I expect
> he will ping me today (because of this email :-) ).
>
> If there is a problem because Albert is just too busy we should at least try to find out
> any reasonable way how to handle this. Like in Linux ARM-SOC custodian?

I think this traversing the actual development process in a different direction
and it must be a valid point that need to discuss.

Apart from this, I'm experienced an another isuue where some of the subsystem
patches (say for example spi stuff) are pushed in a different direction.
http://patchwork.ozlabs.org/patch/346015/

These are the qspi stuff from freescale, and I didn't understand why
these goes into
u-boot-arm/master. And there is no intimation of mine as well.

Issue is that the driver itself is not in a proper shape, why does
subsystem patches were
pushed without the the review tag from a respective custodians.

Please try to discuss this point as well "Each subsystem patch(es)
should be pushed
if and only if the respective custodian should marked the review tag"

thanks!
-- 
Jagan.