From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC][PULL-REQ] MTD update
Date: Wed, 2 Jan 2013 21:22:48 -0600 [thread overview]
Message-ID: <1357183368.14228.22@snotra> (raw)
In-Reply-To: <20130102153333.GB14738@bill-the-cat> (from trini@ti.com on Wed Jan 2 09:33:33 2013)
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
prev parent reply other threads:[~2013-01-03 3:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-28 12:17 [U-Boot] [RFC][PULL-REQ] MTD update Sergey Lapin
2012-12-28 13:51 ` Wolfgang Denk
2012-12-28 15:07 ` Sergey Lapin
2012-12-28 15:14 ` Wolfgang Denk
2012-12-28 13:59 ` Tom Rini
2012-12-29 20:54 ` Sergey Lapin
2012-12-29 21:03 ` Marek Vasut
2012-12-29 21:52 ` Wolfgang Denk
2012-12-29 22:20 ` Sergey Lapin
2012-12-29 23:13 ` Sergey Lapin
2012-12-29 23:21 ` Marek Vasut
2012-12-29 23:33 ` Wolfgang Denk
2012-12-30 0:35 ` Sergey Lapin
2012-12-30 2:54 ` Vikram Narayanan
2013-01-02 15:33 ` Tom Rini
2013-01-03 3:22 ` Scott Wood [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1357183368.14228.22@snotra \
--to=scottwood@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox