All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.