public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14
Date: Sun, 22 Jun 2014 08:59:37 +0200	[thread overview]
Message-ID: <53A67ED9.2090705@denx.de> (raw)
In-Reply-To: <53A3E9DB.3040809@denx.de>

Hello Scott,

Am 20.06.2014 09:59, schrieb Heiko Schocher:
> Hello Scott,
>
> Am 20.06.2014 01:45, schrieb Scott Wood:
>> On Thu, 2014-06-19 at 12:34 +0200, Heiko Schocher wrote:
>>> Hello Tom, Scott,
>>>
>>> Am 18.06.2014 23:42, schrieb Tom Rini:
[...]
>>> I really fear a patch "git format-patch -o ubifs-resync 2.6.29-rc6..v3.14 fs/ubifs"
>>> (The result from this command are 355 patches ...)
>>>
>>> So, in sum, this are 795 patches + missing ubi patches which must be
>>> applied/reworked/reviewed... Sounds painful...
>>
>> I don't know about ubifs, but the core NAND code (and apparently the
>> core UBI code) is currently synced with Linux 3.7.1.
>>
>>> So another question is:
>>> How to generate an update-sync patch:
>>>
>>> version a):
>>> - copy the new linux files from Linux v3.14 to U-Boot
>>> - work in the U-Boot specific changes
>>> - make a patch from this
>>>
>>> Is this really different to:
>>>
>>> version b):
>>> - git format-patch -o mtd-resync v3.7..v3.14 drivers/mtd/nand
>>> - apply them
>>> - make a patch from this
>>
>> It is different because "work in the U-Boot specific changes" is a
>> manual, error-prone step compared to letting git do most of the work.
>>
>>> Currently it is differrent, as I introduced the complete linux code
>>> and marked unused/different code in U-Boot with __UBOOT__. If I delete
>>> this pieces ... version a) and b) should be the same.
>>>
>>> I try it ... if I not give up due to count of patches ...
>>
>> Again, there's no need to go patch-by-patch. We haven't done so on
>> prior updates.
>
> I try it this way.

Ok, did a "git diff v3.7.1..v3.14 ..." for drivers/mtd/nand and
drivers/mtd/mtd*.{c,h} and applied it with "git am -3 ..." after
fetching the Linux tree into my U-boot repository ... this
command worked now nice ... but there are subtle diffs between
the sources in the "copied from linux" tree and the "git am -3"
tree ... which did not pop up when doing a "git am -3 ...", just
detected them because I could do a diff between "my copied from linux"
version and the "git am -3 ..." created version!

Also this does not work correct for "drivers/mtd/ubi" ... hard to
describe what went wrong ... maybe the base from the code in U-Boot
is not v3.7.1, there are a lot of merge errors ... scan.c is not
longer in linux code, therefore attach.c is now there ... and with
this change "git am -3 ..." seem to have problems... as there
resist old function names which were in scan.c, but now missing ...

Before digging in it, and maybe lost a lot of hours ... I did
a diff between my old version (copying the files) and the new
version with git diff ... and except the expected differences
as I let the complete linux code in U-Boot and marked U-Boot
specific Code with __UBOOT__ there are small differences:

"git diff HEAD..20140620" shows:

HEAD: current version, created with "git am -3 ..."
20140620: my old ML posted version created with copying linux files

just two examples:

[...]
diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
index 31e4289b..39daeab 100644
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
[...]
@@ -316,7 +416,7 @@ static int concat_erase(struct mtd_info *mtd, struct erase_info *instr)
                  * to-be-erased area begins. Verify that the starting
                  * offset is aligned to this region's erase size:
                  */
-               if (instr->addr & (erase_regions[i].erasesize - 1))
+               if (i < 0 || instr->addr & (erase_regions[i].erasesize - 1))
                         return -EINVAL;

                 /*

looking into the linux history I see this commit:

commit ebf2e93036907fe2a7ddab942aa63d35f97f3b2b
Author: Roel Kluin <roel.kluin@gmail.com>
Date:   Fri Sep 18 12:51:49 2009 -0700

     mtd: mtdconcat: prevent a read from eraseregions[-1]

     If the erase region was found in the first iteration we read from
     eraseregions[-1]

Seems a necessary bugifx change ...
Why is this missing in the "git am -3" version ... ? (As it is a
change before v3.7.1? But then the question is why it is missing
in current U-Boot code ...

Is it intentionally or just a mistake? I have no chance to decide
this ...

Next example:
[...]
@@ -511,9 +635,6 @@ static int concat_block_markbad(struct mtd_info *mtd, loff_t ofs)
         struct mtd_concat *concat = CONCAT(mtd);
         int i, err = -EINVAL;

-       if (!mtd_can_have_bb(concat->subdev[0]))
-               return 0;
-
         for (i = 0; i < concat->num_subdev; i++) {
                 struct mtd_info *subdev = concat->subdev[i];

[...]

This Code remains in the "git am -3 ..." version ... why?

Ah, here I found the remove commit in linux:

http://git.denx.de/?p=linux-denx.git;a=commitdiff;h=79186876441278e7276d335448a4cb47fc4c1d8e

So ... why remains this code in the "git am -3 ..." version? This
change is in linux v3.7.1 ... so why it is not in U-Boot? No chance to
understand this ...

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__ ...

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

  reply	other threads:[~2014-06-22  6:59 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-17  7:15 [U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14 Heiko Schocher
2014-06-17  7:15 ` [U-Boot] [PATCH v4 1/3] lib, rbtree: " Heiko Schocher
2014-06-17  7:15 ` [U-Boot] [PATCH v4 2/3] lib, list_sort: add list_sort from linux 3.14 Heiko Schocher
2014-06-17  7:15 ` [U-Boot] [PATCH v4 3/3] mtd, ubi, ubifs: resync with Linux-3.14 Heiko Schocher
2014-06-17 15:54 ` [U-Boot] [PATCH v4 0/3] " Scott Wood
2014-06-18  7:55   ` Heiko Schocher
2014-06-18 21:24     ` Scott Wood
2014-06-18 21:42       ` Tom Rini
2014-06-19 10:34         ` Heiko Schocher
2014-06-19 23:45           ` Scott Wood
2014-06-20  7:59             ` Heiko Schocher
2014-06-22  6:59               ` Heiko Schocher [this message]
2014-06-22  7:36                 ` Wolfgang Denk
2014-06-23 15:05                   ` Tom Rini
2014-06-24  4:48                     ` Heiko Schocher
2014-06-24  6:58                       ` Marek Vasut
2014-06-24 14:36                         ` Tom Rini
2014-06-24 14:39                       ` Tom Rini
2014-06-25  4:50                         ` Heiko Schocher
2014-06-24 19:19                 ` Scott Wood
2014-06-25  4:56                   ` Heiko Schocher
2014-06-26  7:51                   ` Wolfgang Denk
2014-06-30 20:20                     ` Scott Wood
2014-06-30 22:56                       ` Wolfgang Denk
2014-06-30 23:09                         ` Scott Wood
2014-07-01 10:45                           ` Wolfgang Denk
2014-07-06 18:04                             ` Wolfgang Denk
2014-07-07 16:12                           ` Tom Rini
2014-07-07 17:24                             ` Wolfgang Denk
2014-07-07 19:59                             ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53A67ED9.2090705@denx.de \
    --to=hs@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox