[U-Boot] [RFC][PULL-REQ] MTD update
Hi, all!
As I failed to submit 250KB patch to the list I will send this pull request
This patch is not for inclusion yet. This patch is just update of u-boot MTD with Linux kernel's MTD v3.8-rc.
The following changes since commit f8cfcf1b1c7543d5dd103359376a3319301143bc:
env: don't generate callback list entries for SPL (2012-12-22 05:57:16 -0700)
are available in the git repository at: git://github.com/slapin/uboot-allwinner.git upstream-mtd
Sergey Lapin (1): MTD resync from Linux-3.8-rc2+ (master)
common/cmd_nand.c | 18 +- drivers/mtd/Makefile | 4 +- drivers/mtd/mtdcore.c | 372 +++++++ drivers/mtd/nand/nand_base.c | 2274 ++++++++++++++++++++++++----------------- drivers/mtd/nand/nand_bbt.c | 839 ++++++++-------- drivers/mtd/nand/nand_ids.c | 21 +- drivers/mtd/nand/nand_util.c | 19 +- include/linux/mtd/bbm.h | 119 ++- include/linux/mtd/flashchip.h | 58 ++ include/linux/mtd/mtd-abi.h | 189 +++- include/linux/mtd/mtd.h | 372 +++++--- include/linux/mtd/nand.h | 246 +++-- include/linux/types.h | 2 + include/nand.h | 11 +- 14 files changed, 2848 insertions(+), 1696 deletions(-) create mode 100644 include/linux/mtd/flashchip.h
Dear Sergey Lapin,
In message 20121228121741.GA29289@build.ihdev.net you wrote:
As I failed to submit 250KB patch to the list
You did not fail. You just have to be patient until a moderator finds time to review and acknowledge your posting. Given that this is vacation time, you should even allow for more time.
I will send this pull request
This will not work. All patches have to be posted here, so they are logged in patchwork.
Best regards,
Wolfgang Denk
On Fri, Dec 28, 2012 at 02:51:52PM +0100, Wolfgang Denk wrote:
Dear Sergey Lapin,
In message 20121228121741.GA29289@build.ihdev.net you wrote:
As I failed to submit 250KB patch to the list
You did not fail. You just have to be patient until a moderator finds time to review and acknowledge your posting. Given that this is vacation time, you should even allow for more time.
I will send this pull request
This will not work. All patches have to be posted here, so they are logged in patchwork.
Best regards,
This is RFC patch, so I hope these requirement can be laxed, as I don't ask for this patch inclusion yet, only review.
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de The human race is faced with a cruel choice: work or daytime tele- vision.
Dear Sergey Lapin,
In message 20121228150717.GB29289@build.ihdev.net you wrote:
This is RFC patch, so I hope these requirement can be laxed, as I don't ask for this patch inclusion yet, only review.
It's like with out of tree code: If you're out of tree, you don't exist. If the patches have not been posted here, they don't get reviewed here, i. e. they don't exist.
Best regards,
Wolfgang Denk
On Fri, Dec 28, 2012 at 07:17:42AM -0500, Sergey Lapin wrote:
Hi, all!
As I failed to submit 250KB patch to the list I will send this pull request
This patch is not for inclusion yet. This patch is just update of u-boot MTD with Linux kernel's MTD v3.8-rc.
First, while I appreciate the effort, I'd rather us sync with v3.7 release rather than the in-flux v3.8. Second, can you please look at the archives about how we've done these re-syncs before? I really don't want to take a single giant patch and we're usually able to break this up into chunks. Thanks!
On Fri, Dec 28, 2012 at 06:59:53AM -0700, Tom Rini wrote:
On Fri, Dec 28, 2012 at 07:17:42AM -0500, Sergey Lapin wrote:
Hi, all!
As I failed to submit 250KB patch to the list I will send this pull request
This patch is not for inclusion yet. This patch is just update of u-boot MTD with Linux kernel's MTD v3.8-rc.
First, while I appreciate the effort, I'd rather us sync with v3.7 release rather than the in-flux v3.8. Second, can you please look at the archives about how we've done these re-syncs before? I really don't want to take a single giant patch and we're usually able to break this up into chunks. Thanks!
current v3.8 version is not that much different from v3.7, and very few, but interesting changes there, so I hope we're not going for version numbers here.
I try to produce proper splitted version, but it is not going to be bisectable then.
-- Tom
Dear Sergey Lapin,
On Fri, Dec 28, 2012 at 06:59:53AM -0700, Tom Rini wrote:
On Fri, Dec 28, 2012 at 07:17:42AM -0500, Sergey Lapin wrote:
Hi, all!
As I failed to submit 250KB patch to the list I will send this pull request
This patch is not for inclusion yet. This patch is just update of u-boot MTD with Linux kernel's MTD v3.8-rc.
First, while I appreciate the effort, I'd rather us sync with v3.7 release rather than the in-flux v3.8. Second, can you please look at the archives about how we've done these re-syncs before? I really don't want to take a single giant patch and we're usually able to break this up into chunks. Thanks!
current v3.8 version is not that much different from v3.7, and very few, but interesting changes there, so I hope we're not going for version numbers here.
Can you elaborate on these interesting changes please? Is there anything in particular that's important compared to stable 3.7.1 ?
I try to produce proper splitted version, but it is not going to be bisectable then.
Best regards, Marek Vasut
Dear Sergey Lapin,
In message 20121229205429.GA9924@build.ihdev.net you wrote:
First, while I appreciate the effort, I'd rather us sync with v3.7 release rather than the in-flux v3.8. Second, can you please look at the archives about how we've done these re-syncs before? I really don't want to take a single giant patch and we're usually able to break this up into chunks. Thanks!
current v3.8 version is not that much different from v3.7, and very few, but interesting changes there, so I hope we're not going for version numbers here.
Tom is right when asking to use a stable kernel tree version as starting point. Said "interesting changes" may be added in a second step, once we have proven that the stable code is actually working stable for us, too.
I try to produce proper splitted version, but it is not going to be bisectable then.
I cannot see why this would have to be the case. Bisectability has to be maintained.
Best regards,
Wolfgang Denk
On Sat, Dec 29, 2012 at 10:52:50PM +0100, Wolfgang Denk wrote:
Dear Sergey Lapin,
In message 20121229205429.GA9924@build.ihdev.net you wrote:
First, while I appreciate the effort, I'd rather us sync with v3.7 release rather than the in-flux v3.8. Second, can you please look at the archives about how we've done these re-syncs before? I really don't want to take a single giant patch and we're usually able to break this up into chunks. Thanks!
current v3.8 version is not that much different from v3.7, and very few, but interesting changes there, so I hope we're not going for version numbers here.
Tom is right when asking to use a stable kernel tree version as starting point. Said "interesting changes" may be added in a second step, once we have proven that the stable code is actually working stable for us, too.
OK, will rebase.
I try to produce proper splitted version, but it is not going to be bisectable then.
I cannot see why this would have to be the case. Bisectability has to be maintained.
Well, if you mean, by bisectable, that it will compile, then yes, it can be done, but I still can't find a way to properly split patch for it to obey to reasoning behind bisect, in this case.
All the best, S.
On Sat, Dec 29, 2012 at 05:20:48PM -0500, Sergey Lapin wrote:
On Sat, Dec 29, 2012 at 10:52:50PM +0100, Wolfgang Denk wrote:
Dear Sergey Lapin,
In message 20121229205429.GA9924@build.ihdev.net you wrote:
First, while I appreciate the effort, I'd rather us sync with v3.7 release rather than the in-flux v3.8. Second, can you please look at the archives about how we've done these re-syncs before? I really don't want to take a single giant patch and we're usually able to break this up into chunks. Thanks!
current v3.8 version is not that much different from v3.7, and very few, but interesting changes there, so I hope we're not going for version numbers here.
Tom is right when asking to use a stable kernel tree version as starting point. Said "interesting changes" may be added in a second step, once we have proven that the stable code is actually working stable for us, too.
OK, will rebase.
Well, I reviewed the difference with 3.7.1 and 3.8-rc's MTD, and I see some changes I critically depend on. These are very small, though. The rest can be added for completeness. I can make these changes into separate patch, will it be fine with you?
Dear Sergey Lapin,
On Sat, Dec 29, 2012 at 05:20:48PM -0500, Sergey Lapin wrote:
On Sat, Dec 29, 2012 at 10:52:50PM +0100, Wolfgang Denk wrote:
Dear Sergey Lapin,
In message 20121229205429.GA9924@build.ihdev.net you wrote:
First, while I appreciate the effort, I'd rather us sync with v3.7 release rather than the in-flux v3.8. Second, can you please look at the archives about how we've done these re-syncs before? I really don't want to take a single giant patch and we're usually able to break this up into chunks. Thanks!
current v3.8 version is not that much different from v3.7, and very few, but interesting changes there, so I hope we're not going for version numbers here.
Tom is right when asking to use a stable kernel tree version as starting point. Said "interesting changes" may be added in a second step, once we have proven that the stable code is actually working stable for us, too.
OK, will rebase.
Well, I reviewed the difference with 3.7.1 and 3.8-rc's MTD, and I see some changes I critically depend on.
What changes exactly?
These are very small, though. The rest can be added for completeness. I can make these changes into separate patch, will it be fine with you?
Please do.
Best regards, Marek Vasut
Dear Sergey Lapin,
In message 20121229231332.GC9924@build.ihdev.net you wrote:
Tom is right when asking to use a stable kernel tree version as starting point. Said "interesting changes" may be added in a second step, once we have proven that the stable code is actually working stable for us, too.
OK, will rebase.
Well, I reviewed the difference with 3.7.1 and 3.8-rc's MTD, and I see some changes I critically depend on. These are very small, though. The rest can be added for completeness. I can make these changes into separate patch, will it be fine with you?
Ideally you should come up with a workign implementation based on the current stable tree. The locate any additional commits in Linux that are needed / useful from your point of view, and check if these can be applied _directly_ (i. e. the unmodified Linux commits) to the U-Boot tree. If we can do this, any future updates will be much easier, so this is a good test for the benefits of the new version.
Best regards,
Wolfgang Denk
On Sun, Dec 30, 2012 at 12:33:31AM +0100, Wolfgang Denk wrote:
Dear Sergey Lapin,
In message 20121229231332.GC9924@build.ihdev.net you wrote:
Tom is right when asking to use a stable kernel tree version as starting point. Said "interesting changes" may be added in a second step, once we have proven that the stable code is actually working stable for us, too.
OK, will rebase.
Well, I reviewed the difference with 3.7.1 and 3.8-rc's MTD, and I see some changes I critically depend on. These are very small, though. The rest can be added for completeness. I can make these changes into separate patch, will it be fine with you?
Ideally you should come up with a workign implementation based on the current stable tree. The locate any additional commits in Linux that are needed / useful from your point of view, and check if these can be applied _directly_ (i. e. the unmodified Linux commits) to the U-Boot tree. If we can do this, any future updates will be much easier, so this is a good test for the benefits of the new version.
Well, direct application of Linux's commits will not work mostly because lower level functions like timers have slightly different implementations. If we'd implement jiffies and associated macros in u-boot, that'd be awesome, but maybe an overkill, and is also out of scope of these patches and not in field of my interests. Simple things, like constant changes will work, but code changes in nand_base.c won't work I'm afraid.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Let's say the docs present a simplified view of reality... :-) - Larry Wall in 6940@jpl-devvax.JPL.NASA.GOV
On 12/28/2012 7:29 PM, Tom Rini wrote:
On Fri, Dec 28, 2012 at 07:17:42AM -0500, Sergey Lapin wrote:
Hi, all!
As I failed to submit 250KB patch to the list I will send this pull request
This patch is not for inclusion yet. This patch is just update of u-boot MTD with Linux kernel's MTD v3.8-rc.
First, while I appreciate the effort, I'd rather us sync with v3.7 release rather than the in-flux v3.8. Second, can you please look at the archives about how we've done these re-syncs before? I really don't want to take a single giant patch and we're usually able to break this up into chunks. Thanks!
Can someone point to the exact thread where such discussion has happened before?
The re-sync has to happen addressing the bisect-ability as well.
Already there was a discussion on syncing the UBI layer. So, if some ideas are thrown, it would be beneficial for both MTD and UBI sync.
Thanks, Vikram
On Sun, Dec 30, 2012 at 08:24:00AM +0530, Vikram Narayanan wrote:
On 12/28/2012 7:29 PM, Tom Rini wrote:
On Fri, Dec 28, 2012 at 07:17:42AM -0500, Sergey Lapin wrote:
Hi, all!
As I failed to submit 250KB patch to the list I will send this pull request
This patch is not for inclusion yet. This patch is just update of u-boot MTD with Linux kernel's MTD v3.8-rc.
First, while I appreciate the effort, I'd rather us sync with v3.7 release rather than the in-flux v3.8. Second, can you please look at the archives about how we've done these re-syncs before? I really don't want to take a single giant patch and we're usually able to break this up into chunks. Thanks!
Can someone point to the exact thread where such discussion has happened before?
The re-sync has to happen addressing the bisect-ability as well.
Already there was a discussion on syncing the UBI layer. So, if some ideas are thrown, it would be beneficial for both MTD and UBI sync.
What I was thinking of was: http://en.usenet.digipedia.org/thread/11185/23221/ http://en.usenet.digipedia.org/thread/11185/23218/ http://en.usenet.digipedia.org/thread/11185/28371/
But, from a lazy-poke of a single file, once we get out from the includes section of the files, some git format-patch'ing on the files we share with the kernel, between the last backport hash and v3.7 for example should be applicable with only a bit of hand fixing up. And if one wanted to do this slowly (3.0 to 3.1 to 3.2 to ...) it might be a little easier to manage.
On 01/02/2013 09:33:33 AM, Tom Rini wrote:
On Sun, Dec 30, 2012 at 08:24:00AM +0530, Vikram Narayanan wrote:
On 12/28/2012 7:29 PM, Tom Rini wrote:
On Fri, Dec 28, 2012 at 07:17:42AM -0500, Sergey Lapin wrote:
Hi, all!
As I failed to submit 250KB patch to the list I will send this pull request
This patch is not for inclusion yet. This patch is just update of u-boot MTD with Linux kernel's MTD v3.8-rc.
First, while I appreciate the effort, I'd rather us sync with v3.7 release rather than the in-flux v3.8. Second, can you please look
at
the archives about how we've done these re-syncs before? I really
don't
want to take a single giant patch and we're usually able to break
this
up into chunks. Thanks!
Can someone point to the exact thread where such discussion has happened before?
"git log driver/mtd/nand_base.c" and look for "sync". :-)
The re-sync has to happen addressing the bisect-ability as well.
Already there was a discussion on syncing the UBI layer. So, if some ideas are thrown, it would be beneficial for both MTD and UBI sync.
What I was thinking of was: http://en.usenet.digipedia.org/thread/11185/23221/ http://en.usenet.digipedia.org/thread/11185/23218/ http://en.usenet.digipedia.org/thread/11185/28371/
But, from a lazy-poke of a single file, once we get out from the includes section of the files, some git format-patch'ing on the files we share with the kernel, between the last backport hash and v3.7 for example should be applicable with only a bit of hand fixing up. And if one wanted to do this slowly (3.0 to 3.1 to 3.2 to ...) it might be a little easier to manage.
That's probably overkill, though breaking it into two or three version jumps would improve the ability to bisect where problems come from. In any case, the size of the patch should go down once it stops merging in things that were deliberately left out of U-Boot.
-Scott
participants (6)
-
Marek Vasut -
Scott Wood -
Sergey Lapin -
Tom Rini -
Vikram Narayanan -
Wolfgang Denk