mtd: nand: revive "nand scrub" command
Subsystems (2)
PATCH 1/1 mtd: nand: revive "nand scrub" command
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.
---
drivers/mtd/nand/nand_base.c | 5 +++++ include/linux/mtd/mtd.h | 2 ++ 2 files changed, 7 insertions(+)
drivers/mtd/nand/nand_base.c +5 -0
@@ -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 ;
include/linux/mtd/mtd.h +2 -0
@@ -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 {
Signature · 1 line
1.9.1
PATCH 1/1 mtd: nand: revive "nand scrub" command
Quoted 8 lines · 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.cthat 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
PATCH 1/1 mtd: nand: revive "nand scrub" command
Quoted 11 lines · Scott Wood
Quoted 8 lines · 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.cthat 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 ?
Quoted 2 lines
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
PATCH 1/1 mtd: nand: revive "nand scrub" command
Quoted 8 lines · Marek Vasut
Quoted 7 lines · Scott Wood
Quoted 6 lines · 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.cthat originates in Linux.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
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
PATCH 1/1 mtd: nand: revive "nand scrub" command
Hello Scott,
Am 11.12.2014 22:43, schrieb Scott Wood:
Quoted 24 lines · Marek Vasut
Quoted 8 lines · Scott Wood
Quoted 7 lines · Masahiro Yamada
Quoted 6 lines
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.cthat originates in Linux.Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 3 lines
Quoted 2 lines
Instead, never again do a "start
from scratch" resync the way that the above commit was done.
Quoted 7 lines
Quoted 1 line
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
Signature · 2 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
PATCH 1/1 mtd: nand: revive "nand scrub" command
Quoted 35 lines · On Fri, 12 Dec 2014 07:19:21 +0100 Heiko Schocher <[email protected]> wrote:
Hello Scott,
Am 11.12.2014 22:43, schrieb Scott Wood:
Quoted 24 lines · Marek Vasut
Quoted 8 lines · Scott Wood
Quoted 7 lines · Masahiro Yamada
Quoted 6 lines
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.cthat originates in Linux.Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 3 lines
Quoted 2 lines
Instead, never again do a "start
from scratch" resync the way that the above commit was done.Quoted 7 lines
Quoted 1 line
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
Quoted 5 lines
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
PATCH 1/1 mtd: nand: revive "nand scrub" command
Quoted 38 lines · Masahiro Yamada
On Fri, 12 Dec 2014 07:19:21 +0100
Quoted 35 lines · Heiko Schocher
Hello Scott,
Am 11.12.2014 22:43, schrieb Scott Wood:
Quoted 31 lines · Marek Vasut
Quoted 8 lines · Scott Wood
Quoted 7 lines · Masahiro Yamada
Quoted 6 lines
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.cthat originates in Linux.Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
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
Quoted 6 lines
Quoted 4 lines
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
PATCH 1/1 mtd: nand: revive "nand scrub" command
Quoted 39 lines · Marek Vasut
Quoted 38 lines · Masahiro Yamada
On Fri, 12 Dec 2014 07:19:21 +0100
Quoted 35 lines · Heiko Schocher
Hello Scott,
Am 11.12.2014 22:43, schrieb Scott Wood:
Quoted 31 lines · Marek Vasut
Quoted 8 lines · Scott Wood
Quoted 7 lines · Masahiro Yamada
Quoted 6 lines
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.cthat originates in Linux.Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
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
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
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
PATCH 1/1 mtd: nand: revive "nand scrub" command
Quoted 60 lines · Scott Wood
Quoted 39 lines · Marek Vasut
Quoted 38 lines · Masahiro Yamada
On Fri, 12 Dec 2014 07:19:21 +0100
Quoted 35 lines · Heiko Schocher
Hello Scott,
Am 11.12.2014 22:43, schrieb Scott Wood:
Quoted 31 lines · Marek Vasut
Quoted 8 lines · Scott Wood
Quoted 7 lines · Masahiro Yamada
Quoted 6 lines
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.cthat originates in Linux.Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
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.htmlQuoted 8 lines
Quoted 6 lines
Quoted 4 lines
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.
Quoted 6 lines
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 commit5b8e6bb517ea4.
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.
Signature · 8 lines
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>
PATCH 1/1 mtd: nand: revive "nand scrub" command
Hello Tom, Scott,
Am 16.12.2014 02:26, schrieb Tom Rini:
Quoted 68 lines · Scott Wood
Quoted 60 lines · Marek Vasut
Quoted 39 lines · Masahiro Yamada
Quoted 38 lines
On Fri, 12 Dec 2014 07:19:21 +0100
Quoted 35 lines · Heiko Schocher
Hello Scott,
Am 11.12.2014 22:43, schrieb Scott Wood:
Quoted 31 lines · Marek Vasut
Quoted 8 lines · Scott Wood
Quoted 7 lines · Masahiro Yamada
Quoted 6 lines
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.cthat originates in Linux.Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
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.htmlQuoted 8 lines
Quoted 6 lines
Quoted 4 lines
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.
Quoted 6 lines
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 commit5b8e6bb517ea4.
Quoted 3 lines
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
Signature · 2 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
PATCH 1/1 mtd: nand: revive "nand scrub" command
Quoted 7 lines · Heiko Schocher
Hello Tom, Scott,
Am 16.12.2014 02:26, schrieb Tom Rini:
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 3 lines
So ...
Who will send a "delete ifdef" patch?
I will.
Quoted 3 lines
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
PATCH 1/1 mtd: nand: revive "nand scrub" command
Hello Scott,
Am 16.12.2014 07:24, schrieb Scott Wood:
Quoted 10 lines · Heiko Schocher
Quoted 9 lines
Hello Tom, Scott,
Am 16.12.2014 02:26, schrieb Tom Rini:
Quoted 3 lines
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 ...
Quoted 8 lines
Quoted 5 lines
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.
Quoted 5 lines
Quoted 3 lines
So ...
Who will send a "delete ifdef" patch?
I will.
Thanks!
Quoted 6 lines
Quoted 4 lines
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
Signature · 2 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
PATCH 1/1 mtd: nand: revive "nand scrub" command
In reply to Scott WoodHi Scott,
Quoted 16 lines · On Tue, 16 Dec 2014 00:24:06 -0600 Scott Wood <[email protected]> wrote:
Quoted 7 lines · Heiko Schocher
Hello Tom, Scott,
Am 16.12.2014 02:26, schrieb Tom Rini:
Quoted 3 lines
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.
Quoted 7 lines
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 ...
Quoted 8 lines
I understand that for some of the mtd parts, but the nand code did have a relatively clean base.
Quoted 3 lines
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