[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[Masahiro Yamada]

Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14),
the "nand scrub" command has not been working.

The scrub is a U-Boot extension and we have to modify nand_base.c
that originates in Linux.

Mark the code with #ifdef __UBOOT__ so we will never accidentally
drop it when we re-sync the NAND framework with Linux in the future.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Heiko Schocher <hs@denx.de>
---

 drivers/mtd/nand/nand_base.c | 5 +++++
 include/linux/mtd/mtd.h      | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 70e780c..83bd033 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2905,8 +2905,13 @@ int nand_erase_nand(struct mtd_info *mtd, struct erase_info *instr,
 		WATCHDOG_RESET();
 
 		/* Check if we have a bad block, we do not erase bad blocks! */
+#ifdef __UBOOT__
+		if (!instr->scrub && nand_block_checkbad(mtd, ((loff_t) page) <<
+					chip->page_shift, 0, allowbbt)) {
+#else
 		if (nand_block_checkbad(mtd, ((loff_t) page) <<
 					chip->page_shift, 0, allowbbt)) {
+#endif
 			pr_warn("%s: attempt to erase a bad block at page 0x%08x\n",
 				    __func__, page);
 			instr->state = MTD_ERASE_FAILED;
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 8666413..2b4e218 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -52,7 +52,9 @@ struct erase_info {
 	u_long priv;
 	u_char state;
 	struct erase_info *next;
+#ifdef __UBOOT__
 	int scrub;
+#endif
 };
 
 struct mtd_erase_region_info {
-- 
1.9.1

[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[Scott Wood]

On Thu, 2014-12-11 at 19:49 +0900, Masahiro Yamada wrote:
> Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14),
> the "nand scrub" command has not been working.
> 
> The scrub is a U-Boot extension and we have to modify nand_base.c
> that originates in Linux.
> 
> Mark the code with #ifdef __UBOOT__ so we will never accidentally
> drop it when we re-sync the NAND framework with Linux in the future.

No more "#ifdef __UBOOT__" please.  Instead, never again do a "start
from scratch" resync the way that the above commit was done.

-Scott

[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[Marek Vasut]

On Thursday, December 11, 2014 at 09:37:10 PM, Scott Wood wrote:
> On Thu, 2014-12-11 at 19:49 +0900, Masahiro Yamada wrote:
> > Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14),
> > the "nand scrub" command has not been working.
> > 
> > The scrub is a U-Boot extension and we have to modify nand_base.c
> > that originates in Linux.
> > 
> > Mark the code with #ifdef __UBOOT__ so we will never accidentally
> > drop it when we re-sync the NAND framework with Linux in the future.
> 
> No more "#ifdef __UBOOT__" please.

Do you happen to have a helpful suggestion how to clearly mark those bits of 
code then please ?

> Instead, never again do a "start
> from scratch" resync the way that the above commit was done.

This was already discussed, no need to revive this topic here now.

Best regards,
Marek Vasut

[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[Scott Wood]

On Thu, 2014-12-11 at 22:37 +0100, Marek Vasut wrote:
> On Thursday, December 11, 2014 at 09:37:10 PM, Scott Wood wrote:
> > On Thu, 2014-12-11 at 19:49 +0900, Masahiro Yamada wrote:
> > > Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14),
> > > the "nand scrub" command has not been working.
> > > 
> > > The scrub is a U-Boot extension and we have to modify nand_base.c
> > > that originates in Linux.
> > > 
> > > Mark the code with #ifdef __UBOOT__ so we will never accidentally
> > > drop it when we re-sync the NAND framework with Linux in the future.
> > 
> > No more "#ifdef __UBOOT__" please.
> 
> Do you happen to have a helpful suggestion how to clearly mark those bits of 
> code then please ?

This was already discussed. :-)

See the archives for why I think this is bad.

> > Instead, never again do a "start
> > from scratch" resync the way that the above commit was done.
> 
> This was already discussed, no need to revive this topic here now.

Sorry, but these patches fixing breakages that resulted from that merge
demonstrate that there is a need to revive it, if there's anyone that
still thinks it's a good idea -- Heiko seemed to be in agreement that
there's no need to do that for future syncs:
http://lists.denx.de/pipermail/u-boot/2014-November/194256.html

-Scott

[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[Heiko Schocher]

Hello Scott,

Am 11.12.2014 22:43, schrieb Scott Wood:
> On Thu, 2014-12-11 at 22:37 +0100, Marek Vasut wrote:
>> On Thursday, December 11, 2014 at 09:37:10 PM, Scott Wood wrote:
>>> On Thu, 2014-12-11 at 19:49 +0900, Masahiro Yamada wrote:
>>>> Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14),
>>>> the "nand scrub" command has not been working.
>>>>
>>>> The scrub is a U-Boot extension and we have to modify nand_base.c
>>>> that originates in Linux.
>>>>
>>>> Mark the code with #ifdef __UBOOT__ so we will never accidentally
>>>> drop it when we re-sync the NAND framework with Linux in the future.
>>>
>>> No more "#ifdef __UBOOT__" please.
>>
>> Do you happen to have a helpful suggestion how to clearly mark those bits of
>> code then please ?
>
> This was already discussed. :-)
>
> See the archives for why I think this is bad.
>
>>> Instead, never again do a "start
>>> from scratch" resync the way that the above commit was done.
>>
>> This was already discussed, no need to revive this topic here now.
>
> Sorry, but these patches fixing breakages that resulted from that merge
> demonstrate that there is a need to revive it, if there's anyone that
> still thinks it's a good idea -- Heiko seemed to be in agreement that
> there's no need to do that for future syncs:
> http://lists.denx.de/pipermail/u-boot/2014-November/194256.html

Yes, I hope a resync works now fine ... but I prefer to mark the
differences between linux and u-boot somehow, because, you immediately
see the differences between linux and u-boot, when you read the u-boot
code ...

And this mark should not disturb the resync process, or?

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

[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[Masahiro Yamada]

On Fri, 12 Dec 2014 07:19:21 +0100
Heiko Schocher <hs@denx.de> wrote:

> Hello Scott,
> 
> Am 11.12.2014 22:43, schrieb Scott Wood:
> > On Thu, 2014-12-11 at 22:37 +0100, Marek Vasut wrote:
> >> On Thursday, December 11, 2014 at 09:37:10 PM, Scott Wood wrote:
> >>> On Thu, 2014-12-11 at 19:49 +0900, Masahiro Yamada wrote:
> >>>> Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14),
> >>>> the "nand scrub" command has not been working.
> >>>>
> >>>> The scrub is a U-Boot extension and we have to modify nand_base.c
> >>>> that originates in Linux.
> >>>>
> >>>> Mark the code with #ifdef __UBOOT__ so we will never accidentally
> >>>> drop it when we re-sync the NAND framework with Linux in the future.
> >>>
> >>> No more "#ifdef __UBOOT__" please.
> >>
> >> Do you happen to have a helpful suggestion how to clearly mark those bits of
> >> code then please ?
> >
> > This was already discussed. :-)
> >
> > See the archives for why I think this is bad.
> >
> >>> Instead, never again do a "start
> >>> from scratch" resync the way that the above commit was done.
> >>
> >> This was already discussed, no need to revive this topic here now.
> >
> > Sorry, but these patches fixing breakages that resulted from that merge
> > demonstrate that there is a need to revive it, if there's anyone that
> > still thinks it's a good idea -- Heiko seemed to be in agreement that
> > there's no need to do that for future syncs:
> > http://lists.denx.de/pipermail/u-boot/2014-November/194256.html
> 
> Yes, I hope a resync works now fine ... but I prefer to mark the
> differences between linux and u-boot somehow, because, you immediately
> see the differences between linux and u-boot, when you read the u-boot
> code ...
> 

I agree with Heiko.




Best Regards
Masahiro Yamada

[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[Marek Vasut]

On Monday, December 15, 2014 at 11:54:08 AM, Masahiro Yamada wrote:
> On Fri, 12 Dec 2014 07:19:21 +0100
> 
> Heiko Schocher <hs@denx.de> wrote:
> > Hello Scott,
> > 
> > Am 11.12.2014 22:43, schrieb Scott Wood:
> > > On Thu, 2014-12-11 at 22:37 +0100, Marek Vasut wrote:
> > >> On Thursday, December 11, 2014 at 09:37:10 PM, Scott Wood wrote:
> > >>> On Thu, 2014-12-11 at 19:49 +0900, Masahiro Yamada wrote:
> > >>>> Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14),
> > >>>> the "nand scrub" command has not been working.
> > >>>> 
> > >>>> The scrub is a U-Boot extension and we have to modify nand_base.c
> > >>>> that originates in Linux.
> > >>>> 
> > >>>> Mark the code with #ifdef __UBOOT__ so we will never accidentally
> > >>>> drop it when we re-sync the NAND framework with Linux in the future.
> > >>> 
> > >>> No more "#ifdef __UBOOT__" please.
> > >> 
> > >> Do you happen to have a helpful suggestion how to clearly mark those
> > >> bits of code then please ?
> > > 
> > > This was already discussed. :-)
> > > 
> > > See the archives for why I think this is bad.
> > > 
> > >>> Instead, never again do a "start
> > >>> from scratch" resync the way that the above commit was done.
> > >> 
> > >> This was already discussed, no need to revive this topic here now.
> > > 
> > > Sorry, but these patches fixing breakages that resulted from that merge
> > > demonstrate that there is a need to revive it, if there's anyone that
> > > still thinks it's a good idea -- Heiko seemed to be in agreement that
> > > there's no need to do that for future syncs:
> > > http://lists.denx.de/pipermail/u-boot/2014-November/194256.html
> > 
> > Yes, I hope a resync works now fine ... but I prefer to mark the
> > differences between linux and u-boot somehow, because, you immediately
> > see the differences between linux and u-boot, when you read the u-boot
> > code ...
> 
> I agree with Heiko.

I second that.

Best regards,
Marek Vasut

[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[Scott Wood]

On Mon, 2014-12-15 at 12:13 +0100, Marek Vasut wrote:
> On Monday, December 15, 2014 at 11:54:08 AM, Masahiro Yamada wrote:
> > On Fri, 12 Dec 2014 07:19:21 +0100
> > 
> > Heiko Schocher <hs@denx.de> wrote:
> > > Hello Scott,
> > > 
> > > Am 11.12.2014 22:43, schrieb Scott Wood:
> > > > On Thu, 2014-12-11 at 22:37 +0100, Marek Vasut wrote:
> > > >> On Thursday, December 11, 2014 at 09:37:10 PM, Scott Wood wrote:
> > > >>> On Thu, 2014-12-11 at 19:49 +0900, Masahiro Yamada wrote:
> > > >>>> Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14),
> > > >>>> the "nand scrub" command has not been working.
> > > >>>> 
> > > >>>> The scrub is a U-Boot extension and we have to modify nand_base.c
> > > >>>> that originates in Linux.
> > > >>>> 
> > > >>>> Mark the code with #ifdef __UBOOT__ so we will never accidentally
> > > >>>> drop it when we re-sync the NAND framework with Linux in the future.
> > > >>> 
> > > >>> No more "#ifdef __UBOOT__" please.
> > > >> 
> > > >> Do you happen to have a helpful suggestion how to clearly mark those
> > > >> bits of code then please ?
> > > > 
> > > > This was already discussed. :-)
> > > > 
> > > > See the archives for why I think this is bad.
> > > > 
> > > >>> Instead, never again do a "start
> > > >>> from scratch" resync the way that the above commit was done.
> > > >> 
> > > >> This was already discussed, no need to revive this topic here now.
> > > > 
> > > > Sorry, but these patches fixing breakages that resulted from that merge
> > > > demonstrate that there is a need to revive it, if there's anyone that
> > > > still thinks it's a good idea -- Heiko seemed to be in agreement that
> > > > there's no need to do that for future syncs:
> > > > http://lists.denx.de/pipermail/u-boot/2014-November/194256.html
> > > 
> > > Yes, I hope a resync works now fine ... but I prefer to mark the
> > > differences between linux and u-boot somehow, because, you immediately
> > > see the differences between linux and u-boot, when you read the u-boot
> > > code ...
> > 
> > I agree with Heiko.
> 
> I second that.

If you or Heiko want to take over NAND custodianship, the offer is still
there.

I find these ifdefs to be harmful to code legibility, editability, and
searchability.

I find these ifdefs to be harmful to merging from Linux, especially when
the ifndef section is large enough that the ifndef itself doesn't
conflict with the diff context.  This can lead to silent mismerges if
the U-Boot alternative needed to be updated.

I find these ifdefs to be unreliable, because not every change is going
to end up getting marked (e.g. commit 35c204d8a9d0).  This can be
actively harmful if people see some changes marked, and rely on the
markers rather than checking with a diff.  And yes, that means I need to
send a patch to strip out the ifdefs from NAND files, just like I did
back in commit 5b8e6bb517ea4.

-Scott

[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[Tom Rini]

On Mon, Dec 15, 2014 at 05:08:16PM -0600, Scott Wood wrote:
> On Mon, 2014-12-15 at 12:13 +0100, Marek Vasut wrote:
> > On Monday, December 15, 2014 at 11:54:08 AM, Masahiro Yamada wrote:
> > > On Fri, 12 Dec 2014 07:19:21 +0100
> > > 
> > > Heiko Schocher <hs@denx.de> wrote:
> > > > Hello Scott,
> > > > 
> > > > Am 11.12.2014 22:43, schrieb Scott Wood:
> > > > > On Thu, 2014-12-11 at 22:37 +0100, Marek Vasut wrote:
> > > > >> On Thursday, December 11, 2014 at 09:37:10 PM, Scott Wood wrote:
> > > > >>> On Thu, 2014-12-11 at 19:49 +0900, Masahiro Yamada wrote:
> > > > >>>> Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14),
> > > > >>>> the "nand scrub" command has not been working.
> > > > >>>> 
> > > > >>>> The scrub is a U-Boot extension and we have to modify nand_base.c
> > > > >>>> that originates in Linux.
> > > > >>>> 
> > > > >>>> Mark the code with #ifdef __UBOOT__ so we will never accidentally
> > > > >>>> drop it when we re-sync the NAND framework with Linux in the future.
> > > > >>> 
> > > > >>> No more "#ifdef __UBOOT__" please.
> > > > >> 
> > > > >> Do you happen to have a helpful suggestion how to clearly mark those
> > > > >> bits of code then please ?
> > > > > 
> > > > > This was already discussed. :-)
> > > > > 
> > > > > See the archives for why I think this is bad.
> > > > > 
> > > > >>> Instead, never again do a "start
> > > > >>> from scratch" resync the way that the above commit was done.
> > > > >> 
> > > > >> This was already discussed, no need to revive this topic here now.
> > > > > 
> > > > > Sorry, but these patches fixing breakages that resulted from that merge
> > > > > demonstrate that there is a need to revive it, if there's anyone that
> > > > > still thinks it's a good idea -- Heiko seemed to be in agreement that
> > > > > there's no need to do that for future syncs:
> > > > > http://lists.denx.de/pipermail/u-boot/2014-November/194256.html
> > > > 
> > > > Yes, I hope a resync works now fine ... but I prefer to mark the
> > > > differences between linux and u-boot somehow, because, you immediately
> > > > see the differences between linux and u-boot, when you read the u-boot
> > > > code ...
> > > 
> > > I agree with Heiko.
> > 
> > I second that.
> 
> If you or Heiko want to take over NAND custodianship, the offer is still
> there.
> 
> I find these ifdefs to be harmful to code legibility, editability, and
> searchability.
> 
> I find these ifdefs to be harmful to merging from Linux, especially when
> the ifndef section is large enough that the ifndef itself doesn't
> conflict with the diff context.  This can lead to silent mismerges if
> the U-Boot alternative needed to be updated.
> 
> I find these ifdefs to be unreliable, because not every change is going
> to end up getting marked (e.g. commit 35c204d8a9d0).  This can be
> actively harmful if people see some changes marked, and rely on the
> markers rather than checking with a diff.  And yes, that means I need to
> send a patch to strip out the ifdefs from NAND files, just like I did
> back in commit 5b8e6bb517ea4.

As we're neck deep in "See? Scott was right" I'm inclined to go with
what Scott is saying.  We tried it, it actively didn't work, lets step
back, evaluate and move along.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141215/3cbd1acc/attachment.pgp>

[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[Heiko Schocher]

Hello Tom, Scott,

Am 16.12.2014 02:26, schrieb Tom Rini:
> On Mon, Dec 15, 2014 at 05:08:16PM -0600, Scott Wood wrote:
>> On Mon, 2014-12-15 at 12:13 +0100, Marek Vasut wrote:
>>> On Monday, December 15, 2014 at 11:54:08 AM, Masahiro Yamada wrote:
>>>> On Fri, 12 Dec 2014 07:19:21 +0100
>>>>
>>>> Heiko Schocher <hs@denx.de> wrote:
>>>>> Hello Scott,
>>>>>
>>>>> Am 11.12.2014 22:43, schrieb Scott Wood:
>>>>>> On Thu, 2014-12-11 at 22:37 +0100, Marek Vasut wrote:
>>>>>>> On Thursday, December 11, 2014 at 09:37:10 PM, Scott Wood wrote:
>>>>>>>> On Thu, 2014-12-11 at 19:49 +0900, Masahiro Yamada wrote:
>>>>>>>>> Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14),
>>>>>>>>> the "nand scrub" command has not been working.
>>>>>>>>>
>>>>>>>>> The scrub is a U-Boot extension and we have to modify nand_base.c
>>>>>>>>> that originates in Linux.
>>>>>>>>>
>>>>>>>>> Mark the code with #ifdef __UBOOT__ so we will never accidentally
>>>>>>>>> drop it when we re-sync the NAND framework with Linux in the future.
>>>>>>>>
>>>>>>>> No more "#ifdef __UBOOT__" please.
>>>>>>>
>>>>>>> Do you happen to have a helpful suggestion how to clearly mark those
>>>>>>> bits of code then please ?
>>>>>>
>>>>>> This was already discussed. :-)
>>>>>>
>>>>>> See the archives for why I think this is bad.
>>>>>>
>>>>>>>> Instead, never again do a "start
>>>>>>>> from scratch" resync the way that the above commit was done.
>>>>>>>
>>>>>>> This was already discussed, no need to revive this topic here now.
>>>>>>
>>>>>> Sorry, but these patches fixing breakages that resulted from that merge
>>>>>> demonstrate that there is a need to revive it, if there's anyone that
>>>>>> still thinks it's a good idea -- Heiko seemed to be in agreement that
>>>>>> there's no need to do that for future syncs:
>>>>>> http://lists.denx.de/pipermail/u-boot/2014-November/194256.html
>>>>>
>>>>> Yes, I hope a resync works now fine ... but I prefer to mark the
>>>>> differences between linux and u-boot somehow, because, you immediately
>>>>> see the differences between linux and u-boot, when you read the u-boot
>>>>> code ...
>>>>
>>>> I agree with Heiko.
>>>
>>> I second that.
>>
>> If you or Heiko want to take over NAND custodianship, the offer is still
>> there.
>>
>> I find these ifdefs to be harmful to code legibility, editability, and
>> searchability.
>>
>> I find these ifdefs to be harmful to merging from Linux, especially when
>> the ifndef section is large enough that the ifndef itself doesn't
>> conflict with the diff context.  This can lead to silent mismerges if
>> the U-Boot alternative needed to be updated.
>>
>> I find these ifdefs to be unreliable, because not every change is going
>> to end up getting marked (e.g. commit 35c204d8a9d0).  This can be
>> actively harmful if people see some changes marked, and rely on the
>> markers rather than checking with a diff.  And yes, that means I need to
>> send a patch to strip out the ifdefs from NAND files, just like I did
>> back in commit 5b8e6bb517ea4.
>
> As we're neck deep in "See? Scott was right" I'm inclined to go with
> what Scott is saying.  We tried it, it actively didn't work, lets step
> back, evaluate and move along.

Ok, I have no objections against that, it was just my point of view ...

And yes, I missed here and there some pieces when syncing with
linux 3.14 ... sorry for that, but I could not test every scenario for
every board ... and we had no clean base for using git, which at last
in my attempt ended in a big mess when syncing with linux ... so I started
more or less from scratch ...

So ...

Who will send a "delete ifdef" patch?
Who will test, how a resync with linux (saying 3.17 ?) work now with git?

If this test is done, we can decide, which way is the "way to go" ... ?

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

[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[Scott Wood]

On Tue, 2014-12-16 at 07:21 +0100, Heiko Schocher wrote:
> Hello Tom, Scott,
> 
> Am 16.12.2014 02:26, schrieb Tom Rini:
> > As we're neck deep in "See? Scott was right" I'm inclined to go with
> > what Scott is saying.  We tried it, it actively didn't work, lets step
> > back, evaluate and move along.
> 
> Ok, I have no objections against that, it was just my point of view ...
> 
> And yes, I missed here and there some pieces when syncing with
> linux 3.14 ... sorry for that, but I could not test every scenario for
> every board ... and we had no clean base for using git, which at last
> in my attempt ended in a big mess when syncing with linux ... so I started
> more or less from scratch ...

I understand that for some of the mtd parts, but the nand code did have
a relatively clean base.

> So ...
> 
> Who will send a "delete ifdef" patch?

I will.

> Who will test, how a resync with linux (saying 3.17 ?) work now with git?
> 
> If this test is done, we can decide, which way is the "way to go" ... ?

I'll try a 3.18 sync soon.

-Scott

[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[Heiko Schocher]

Hello Scott,

Am 16.12.2014 07:24, schrieb Scott Wood:
> On Tue, 2014-12-16 at 07:21 +0100, Heiko Schocher wrote:
>> Hello Tom, Scott,
>>
>> Am 16.12.2014 02:26, schrieb Tom Rini:
>>> As we're neck deep in "See? Scott was right" I'm inclined to go with
>>> what Scott is saying.  We tried it, it actively didn't work, lets step
>>> back, evaluate and move along.
>>
>> Ok, I have no objections against that, it was just my point of view ...
>>
>> And yes, I missed here and there some pieces when syncing with
>> linux 3.14 ... sorry for that, but I could not test every scenario for
>> every board ... and we had no clean base for using git, which at last
>> in my attempt ended in a big mess when syncing with linux ... so I started
>> more or less from scratch ...
>
> I understand that for some of the mtd parts, but the nand code did have
> a relatively clean base.

Yes, the problem was in the mtd and most notably in the ubi/ubifs code,
IIRC.

>> So ...
>>
>> Who will send a "delete ifdef" patch?
>
> I will.

Thanks!

>
>> Who will test, how a resync with linux (saying 3.17 ?) work now with git?
>>
>> If this test is done, we can decide, which way is the "way to go" ... ?
>
> I'll try a 3.18 sync soon.

Thanks! Please add a little description how you did the resync.

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

[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command

[Masahiro Yamada]

Hi Scott,


On Tue, 16 Dec 2014 00:24:06 -0600
Scott Wood <scottwood@freescale.com> wrote:

> On Tue, 2014-12-16 at 07:21 +0100, Heiko Schocher wrote:
> > Hello Tom, Scott,
> > 
> > Am 16.12.2014 02:26, schrieb Tom Rini:
> > > As we're neck deep in "See? Scott was right" I'm inclined to go with
> > > what Scott is saying.  We tried it, it actively didn't work, lets step
> > > back, evaluate and move along.
> > 
> > Ok, I have no objections against that, it was just my point of view ...
> > 
> > And yes, I missed here and there some pieces when syncing with
> > linux 3.14 ... sorry for that, but I could not test every scenario for
> > every board ... and we had no clean base for using git, which at last
> > in my attempt ended in a big mess when syncing with linux ... so I started
> > more or less from scratch ...
> 
> I understand that for some of the mtd parts, but the nand code did have
> a relatively clean base.
> 
> > So ...
> > 
> > Who will send a "delete ifdef" patch?
> 
> I will.


Given that we have made a decision to turn around,
no point of adding the ifdefs by this patch.

V2 is now on our patchwork.
http://patchwork.ozlabs.org/patch/421803/




Best Regards
Masahiro Yamada