[U-Boot] [SoCFPGA] next steps

[Michal Simek]

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?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141009/386ae93c/attachment.pgp>