[U-Boot] Quick sanity test after my NAND patches
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
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
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
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
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
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
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
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
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
participants (4)
-
Jerry Van Baren -
Paulraj, Sandeep -
Scott Wood -
Wolfgang Denk