From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Sun, 22 Jun 2014 08:59:37 +0200 Subject: [U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14 In-Reply-To: <53A3E9DB.3040809@denx.de> References: <1402989356-14746-1-git-send-email-hs@denx.de> <1403020481.6603.737.camel@snotra.buserror.net> <53A145F0.9010909@denx.de> <1403126679.12851.93.camel@snotra.buserror.net> <20140618214224.GJ26243@bill-the-cat> <53A2BCA4.90500@denx.de> <1403221545.12851.167.camel@snotra.buserror.net> <53A3E9DB.3040809@denx.de> Message-ID: <53A67ED9.2090705@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.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 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