[U-Boot] Quick sanity test after my NAND patches

[U-Boot] Quick sanity test after my NAND patches

[Paulraj, Sandeep]

As most of you know I submitted a lot of patches for the MTD NAND driver to sync up with what's in the kernel.

I did a quick build for the DM355 from the u-boot-nand-flash/next tree.
The board booted up fine with a 2GB NAND device and I was able to perform NAND operations.

There will be issues if a 4GB NAND device is used as cmd_nand.c has to be updated to handle 64 bit variables. I'll work on that as I get time.

Thanks,
Sandeep

[U-Boot] Quick sanity test after my NAND patches

[Scott Wood]

On Fri, Nov 06, 2009 at 02:47:01PM -0600, Paulraj, Sandeep wrote:
> As most of you know I submitted a lot of patches for the MTD NAND driver
> to sync up with what's in the kernel.

They appear to correlate with specific Linux commits -- could you preserve
the authorship and signoffs?  Especially when a copyrightably-sized chunk of
code is being added.

-Scott

[U-Boot] Quick sanity test after my NAND patches

[Jerry Van Baren]

Scott Wood wrote:
> On Fri, Nov 06, 2009 at 02:47:01PM -0600, Paulraj, Sandeep wrote:
>> As most of you know I submitted a lot of patches for the MTD NAND driver
>> to sync up with what's in the kernel.
> 
> They appear to correlate with specific Linux commits -- could you preserve
> the authorship and signoffs?  Especially when a copyrightably-sized chunk of
> code is being added.
> 
> -Scott

I don't know if the technique will work for you (Sandeep), but for the 
libfdt synchronization, I literally extracted the patches from the 
master DTC repository (git format-patch) and applied them (git am).

For the most part, David Gibson and Jon Loeliger made separate patches 
for libfdt vs. the other stuff, so that was very helpful.  Once or twice 
I hand edited the patch to remove patches to non-libfdt files.  I also 
have to change the include/fdtlib.h file path since the DTC puts the 
header file in a different directory.  Hand editing the patches is an 
ugly solution, but the result is very nice since it preserves the 
changes, signoffs, and comments verbatim.

HTH,
gvb

[U-Boot] Quick sanity test after my NAND patches

[Paulraj, Sandeep]

Scott, Jerry,
> 
> Scott Wood wrote:
> > On Fri, Nov 06, 2009 at 02:47:01PM -0600, Paulraj, Sandeep wrote:
> >> As most of you know I submitted a lot of patches for the MTD NAND
> driver
> >> to sync up with what's in the kernel.
> >
> > They appear to correlate with specific Linux commits -- could you
> preserve
> > the authorship and signoffs?  Especially when a copyrightably-sized
> chunk of
Absolutely. Its not my work at all. As I said just trying to sync up with the kernel as somebody has to do it. So always willing to do it the correct way.

> > code is being added.
> >
> > -Scott
> 
> I don't know if the technique will work for you (Sandeep), but for the
> libfdt synchronization, I literally extracted the patches from the
> master DTC repository (git format-patch) and applied them (git am).
This might not work as git-am will complain about not being able to apply clean. 
> 
> For the most part, David Gibson and Jon Loeliger made separate patches
> for libfdt vs. the other stuff, so that was very helpful.  Once or twice
> I hand edited the patch to remove patches to non-libfdt files.  I also
> have to change the include/fdtlib.h file path since the DTC puts the
> header file in a different directory.  Hand editing the patches is an
> ugly solution, but the result is very nice since it preserves the
> changes, signoffs, and comments verbatim.

Is it ok if I send the patches again with the appropriate authors and signoffs.

> 
> HTH,
> gvb

Scott,

Is it possible for you to let me know which patches you are OK with, so that I know what to resend?

Thanks,
Sandeep

[U-Boot] Quick sanity test after my NAND patches

[Jerry Van Baren]

Paulraj, Sandeep wrote:
> Scott, Jerry,

[snip]

>> I don't know if the technique will work for you (Sandeep), but for the
>> libfdt synchronization, I literally extracted the patches from the
>> master DTC repository (git format-patch) and applied them (git am).
> 
> This might not work as git-am will complain about not being able to apply clean. 

I may be missing something, but if you hand-edit the patches so that 
they are still valid patches, they will apply cleanly.  In my hand 
editing, I cut out all patch hunks to non-existing (for me) files (from 
the patch's file name header to the next file name header).  This is 
simply a delete operation so it is pretty hard to screw up.  I also 
changed the file paths for all file references to libfdt.h which is 
simply a substitution problem, again hard to screw up.

I don't know how complex your starting point patches are, so that may be 
what I'm missing.

Note that the MD5 hash will be different between my edited patch and the 
original patch, so you won't be able to correlate the u-boot/libfdt 
patch directly to the DTC/libfdt patch, but that would happen anyway.

[snip]

Best regards,
gvb

[U-Boot] Quick sanity test after my NAND patches

[Paulraj, Sandeep]

> Paulraj, Sandeep wrote:
> > Scott, Jerry,
> 
> [snip]
> 
> >> I don't know if the technique will work for you (Sandeep), but for the
> >> libfdt synchronization, I literally extracted the patches from the
> >> master DTC repository (git format-patch) and applied them (git am).
> >
> > This might not work as git-am will complain about not being able to
> apply clean.
> 
> I may be missing something, but if you hand-edit the patches so that
> they are still valid patches, they will apply cleanly.  In my hand
> editing, I cut out all patch hunks to non-existing (for me) files (from
> the patch's file name header to the next file name header).  This is
> simply a delete operation so it is pretty hard to screw up.  I also
> changed the file paths for all file references to libfdt.h which is
> simply a substitution problem, again hard to screw up.
> 
> I don't know how complex your starting point patches are, so that may be
> what I'm missing.
This is what I am referring to
> 
> Note that the MD5 hash will be different between my edited patch and the
> original patch, so you won't be able to correlate the u-boot/libfdt
> patch directly to the DTC/libfdt patch, but that would happen anyway.
Yes that's true
> 
> [snip]
> 
> Best regards,
> gvb

Basically if I maintain the correct author and signoff, things should be OK.
I'll do it some way or the other, sooner rather than later.

I'll wait for Scott to say which ones need to be resubmitted.

Thanks,
Sandeep

[U-Boot] Quick sanity test after my NAND patches

[Scott Wood]

Paulraj, Sandeep wrote:
>> I don't know if the technique will work for you (Sandeep), but for the
>> libfdt synchronization, I literally extracted the patches from the
>> master DTC repository (git format-patch) and applied them (git am).
> This might not work as git-am will complain about not being able to apply clean. 

You can apply the patches to your u-boot tree with git am, fixing up any 
conflicts, and then do format-patch on the results.

> Is it possible for you to let me know which patches you are OK with, so that I know what to resend?

I'm most concerned with getting the attribution right on the 'fix "raw" 
reads with ECC syndrome layouts' patch, since that adds significant new 
code -- but ideally any patches that correspond with a patch in Linux 
should look as much like that patch as possible (otherwise, mention in 
the changelog that it is a sync with Linux).  Or if you meant which 
patches I'm OK with merging even after resend, they all look OK.

As for the comment about checkpatch warnings, what was it complaining 
about?  If it's not too bad I'd rather not make stylistic deviations 
from what made it into Linux.

-Scott

[U-Boot] Quick sanity test after my NAND patches

[Paulraj, Sandeep]

Hello Scott,
 
> Paulraj, Sandeep wrote:
> >> I don't know if the technique will work for you (Sandeep), but for the
> >> libfdt synchronization, I literally extracted the patches from the
> >> master DTC repository (git format-patch) and applied them (git am).
> > This might not work as git-am will complain about not being able to
> apply clean.
> 
> You can apply the patches to your u-boot tree with git am, fixing up any
> conflicts, and then do format-patch on the results.
> 
> > Is it possible for you to let me know which patches you are OK with, so
> that I know what to resend?
> 
> I'm most concerned with getting the attribution right on the 'fix "raw"
> reads with ECC syndrome layouts' patch, since that adds significant new
> code -- but ideally any patches that correspond with a patch in Linux
> should look as much like that patch as possible (otherwise, mention in
> the changelog that it is a sync with Linux). 

So I take it that you only want the above patch resent with the correct signoffs.
I'll resend this single patch.
.
> Or if you meant which
> patches I'm OK with merging even after resend, they all look OK.
> 
> As for the comment about checkpatch warnings, what was it complaining
> about?  If it's not too bad I'd rather not make stylistic deviations
> from what made it into Linux.

80 chars per line warning. Do we really need to break this rule while I submit my patch?

Unrelated, but if you have a look at the subpage API, that's absolutely unbelievable; the function header itself is some 150 chars. I don't have a clue as to how it got accepted by the MTD folks.
> 
> -Scott


Also in response to another e-mail from you, I think we need to update nand_ecc.c as well. I'll do that as well as a separate patch.

Thanks,
Sandeep

[U-Boot] Quick sanity test after my NAND patches

[Wolfgang Denk]

Dear Jerry Van Baren,

In message <4AF4971B.9080602@ge.com> you wrote:
>
> > This might not work as git-am will complain about not being able to apply clean. 
> 
> I may be missing something, but if you hand-edit the patches so that 
> they are still valid patches, they will apply cleanly.  In my hand 
> editing, I cut out all patch hunks to non-existing (for me) files (from 
> the patch's file name header to the next file name header).  This is 
> simply a delete operation so it is pretty hard to screw up.  I also 
> changed the file paths for all file references to libfdt.h which is 
> simply a substitution problem, again hard to screw up.

"filterdiff" and/or "editdiff" (from the "patchutils" package of the
distribution of your choice) may be useful tools for such tasks.

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 at denx.de
One essential to success is that you desire be an all-obsessing  one,
your thoughts and aims be co-ordinated, and your energy be concentra-
ted and applied without letup.