Patchwork [U-Boot,RFC,PULL-REQ] MTD update

login
register
mail settings
Submitter Sergey Lapin
Date Dec. 28, 2012, 12:17 p.m.
Message ID <20121228121741.GA29289@build.ihdev.net>
Download mbox
Permalink /patch/208480/
State RFC
Headers show

Pull-request

git://github.com/slapin/uboot-allwinner.git upstream-mtd

Comments

Sergey Lapin - Dec. 28, 2012, 12:17 p.m.
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
Wolfgang Denk - Dec. 28, 2012, 1:51 p.m.
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
Tom Rini - Dec. 28, 2012, 1:59 p.m.
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!
Sergey Lapin - Dec. 28, 2012, 3:07 p.m.
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.
Wolfgang Denk - Dec. 28, 2012, 3:14 p.m.
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
Sergey Lapin - Dec. 29, 2012, 8:54 p.m.
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
Marek Vasut - Dec. 29, 2012, 9:03 p.m.
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
Wolfgang Denk - Dec. 29, 2012, 9:52 p.m.
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
Sergey Lapin - Dec. 29, 2012, 10:20 p.m.
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.
Sergey Lapin - Dec. 29, 2012, 11:13 p.m.
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?
Marek Vasut - Dec. 29, 2012, 11:21 p.m.
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
Wolfgang Denk - Dec. 29, 2012, 11:33 p.m.
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
Sergey Lapin - Dec. 30, 2012, 12:35 a.m.
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>
Vikram Narayanan - Dec. 30, 2012, 2:54 a.m.
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
Tom Rini - Jan. 2, 2013, 3:33 p.m.
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.