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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
