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

[Heiko Schocher]

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.

> 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?

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

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany