[U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14

[Tom Rini]

On Tue, Jun 24, 2014 at 06:48:27AM +0200, Heiko Schocher wrote:
> Hello Tom,
> 
> Am 23.06.2014 17:05, schrieb Tom Rini:
> >On Sun, Jun 22, 2014 at 09:36:43AM +0200, Wolfgang Denk wrote:
> >>Dear Heiko,
> >>
> >>In message<53A67ED9.2090705 at denx.de>  you wrote:
> >>>
> >>>And I have no chance to detect this difference, when using
> >>>"git am -3 ..." ... it just remains in the code ...
> >>>
> >>>I vote for copying the linux files, marking U-Boot specific code
> >>>with __UBOOT__ ...
> >>
> >>Given the complexity of the code  - and of the changes added in U-Boot
> >>to the original (old) Linux code (which were done over a period of
> >>time) - I think indeed that your original approach is the better one;
> >>better both in the sense of requiring less efforts (for creating and
> >>verifying that all chanes were covered), and less risk to miss
> >>individual modifications either from the Linux or from the U-Boot
> >>side.
> >>
> >>Scott, I agree that your suggestion is what usually should work fine,
> >>but here it apparently fails in a number of places that would be time
> >>consuming to sort out - and I would expect that the same would happen
> >>again whenever we update to another new version of the Linux code
> >>base.  So I think we should stick with Heiko's approach here; it
> >>documents clearly what he did, it looks complete, and it is working.
> >>I think it would be a waste of time to redo all the work, just
> >>differently.
> >
> >OK, lets try this.  One worry at the back of my mind is the fallout we
> >had when we re-synced to v3.7.1 and tested things as best we were able
> >to prior to merge.  I think it's too late in the cycle to pull this in
> 
> Yes I fear such fallout too ... I could also test on some boards only,
> the rest is compile clean only ... thats the reason why I had the sync
> serie as RFC ... maybe we create a mtd-test branch? But on the other
> hand, things maybe get tested only, if they are in mainline ...
> 
> >for v2014.07, but lets get something in for v2014.10.  And since v3.15
> 
> Yep, that was my plan too.

OK.

> >is already out, lets do (as part of testing our theories out), a follow
> >up patch to sync up with v3.15.  And finally, I think we need, in order
> >to keep this pain point down, sync per kernel release.
> 
> Ok, I had prepared a v5, posting it soon.
> 
> I try to do also to prepare a seperate sync with v3.15 patch, but give
> me some time ... also I found a bug in current v3.16-rc1 kernel, using
> ubi fastmap, see:
> 
> "UBI: fix rb_tree node comparison in add_map commit buggy?"
> http://lists.infradead.org/pipermail/linux-mtd/2014-June/054348.html
> 
> So current v3.16-rc1 kernel could not attach a ubi volume using
> ubi fastmap and created with a kernel not having commit
> 604b592e6fd3c98f21435e1181ba7723ffc24715 applied ... which is
> the case for v3.14 ... with my fixup, a v3.16-rc1 kernel could
> again attach a v3.14 kernel or U-Boot (with my v3.14 sync patches
> applied) created ubi volume ...
> 
> Maybe we wait with the sync, until this is sorted out?

Yes, that's fine.  Perhaps we'll end up with a sync to v3.14 series, a
v3.15 on top of it, and then backporting your bugfix patch(es) on top of
that.

> To sync us with each kernel release would be a good idea, but the
> problem would be, to find time for it ...

Yes, but I think if we do it more regularly it will be better for us and
take less time.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140624/5204adcf/attachment.pgp>